多用户应用

Question

我正在建立一个学习目的的网络应用程序，它将是一个多用户应用程序。每个用户都有自己的数据。对于如何实现这一点，我不是百分之百肯定。我应该让Model1包含一个int UserId {get;set;}属性来保存用户GUID，还是应该是IdentityUser类型？那么，在我的控制器中，我是否总是考虑到当前登录的查询用户id？我应该能从会议中得到userId吗？

Answer 1

出于某种原因，当涉及到用户对象时，人们似乎会感到害怕，但这与任何其他类型的关系并没有什么不同。是的，如果某个实体是用户“拥有”的，那么用户实体应该有一个外键。

我假设您已经使用了ASP.NET标识，因为您提到了IdentityUser，但您似乎对实体框架如何处理关系感到困惑。从技术上讲，以下两个属性对生成的表具有相同的净效果(例如，名为User_Id的列)

public string User_Id { get; set; }

或

public virtual ApplicationUser User { get; set; }

在第二行中，entity看到您正在关联另一个实体，因此创建一个跟踪该关系的隐式外键将由它自己承担。它不是实体的一部分，但不管如何，它都在数据库表上。这是因为实体框架显然不能将整个用户对象存储在数据库级别的单个列中，也不希望它存储。

尽管如此，用于该关系的代码实际上应该如下所示：

[ForeignKey("User")]
public string UserId { get; set; }
public virtual ApplicationUser User { get; set; }

这做了两件事：

1. 您将获得一个导航属性User，它允许您通过该实体直接访问用户对象，同时还通知entities，需要在这里跟踪实体之间的关系。
2. 您有一个显式的外键属性UserId，它允许您在需要时实际获取外键。如果您想要从select列表中选择相关的项，这通常是必要的，因为select列表只能发布一个基本类型，比如int或string。如果您没有这个属性，那么要实现这种类型的场景肯定会更加困难。

严格地说，ForeignKey属性并不是必需的，因为Entity将根据约定将UserId作为User的外键。但是，我认为最好是明确说明您期望发生的事情，并且在约定可能不正确的情况下，使用ForeignKey的习惯将确保事情仍然按其应有的方式工作。

最后，关于授权，是的，您将按用户筛选实体，以便每个用户只看到他们应该看到的内容。例如：

var widgets = db.Widgets.Where(m => m.UserId == User.Identity.GetUserId());

或者，在显示或允许用户编辑单个项目的情况下：

var widget = db.Widgets.SingleOrDefault(m => m.Id == widgetId && m.UserId == User.Identity.GetUserId());
if (widget == null)
{
    return new HttpNotFoundResult();
}

这样，用户甚至对应用程序中的其他“小部件”没有可见性。如果不是他们的，他们就会得到404，就像它不存在一样。

Answer 2

试着想想所有的情景。你认为有可能共享登录吗？不需要登录或多次登录就需要访问的用户也可能造成问题。在大多数情况下，使用UserId是一个很好的解决方案，但要确保您知道是谁在使用它，以及如何使用它。