使用 EF7、MVC6 ASP.NET 标识保存和检索创建者用户信息

本文关键字：检索 创建者 用户 信息 保存 标识 EF7 MVC6 ASP NET 使用 | 更新日期: 2023-09-27 18:36:42

我使用的是最新的MVC6和实体框架7，但是我相信MVC5和实体框架6中使用的许多技术也可以帮助回答我的问题。

我的数据库中几乎所有表都有以下 4 个用于审核的字段：创建日期、创建者、修改日期、修改者。

我正在尝试找出在将项目保存到数据库时应该将内置的 IdentityUser（AspNetUsers 表）中的哪个字段存储在 CreatedBy 字段中。

我首先尝试使用"用户名"，因为通过调用 User.Identity.Name 并在保存时将其传递到存储库即可轻松访问它。以下是我如何使用 Fluent API 配置 EF，以帮助检索创建项目的用户及其所有字段：

builder.Entity<BlogPost>()
    .Property(bp => bp.CreatedBy)
    .HasMaxLength(256);
builder.Entity<BlogPost>()
    .HasOne(bp => bp.CreatedByUser)
    .WithMany()
    .HasForeignKey(bp => bp.CreatedBy)
    .HasPrincipalKey(u => u.UserName);

但后来我注意到实体框架在尝试添加迁移和创建数据库时大喊大叫，因为需要将用户名设置为主键，否则它不能用作另一个表中的外键。

然后我到了我认为我只会使用实际 ID 的地步，这是一个 GUID。这种技术的问题在于，在尝试保存时，当前登录用户的 ID 不容易获得："User.Identity.Name"就是全部。

下面是我希望具有 EF 和审核经验的人尝试为我回答的几个问题：

  1. 人们甚至不再在所有表中使用审核字段了吗？我没有看到很多人对此提出问题Microsoft而且使用他们的新身份系统和自定义审核字段绝对不容易。

  2. 我应该在我的创建者字段中存储用户名或 ID。有人说这可能是偏好，但我真的很想知道Microsoft可能会推动新身份的方向。存储 Id 的问题在于保存时很难获取它，存储用户名的问题是它不是 AspNetUsers 表中的主键。

    3. 我真的只是想知道在使用 EF 时处理审核

  3. 的良好模式，该 EF 在保存时处理审核，检索用户并将其设置为从数据库中提取记录时需要它的实体上的导航属性。

使用 EF7、MVC6 ASP.NET 标识保存和检索创建者用户信息

我正在尝试从内置的身份用户中找出哪个字段 （AspNetUsers 表）我应该存储在创建者字段中，当 将项目保存到数据库。

使用本网站的人的用户名（在Thread.CurrentPrincipal上，通过User.Identity.Name ASP.Net 访问）。还有谁？这是使用您的网站的当前经过身份验证的用户的身份，也是您应该放入审核表中的内容。

人们甚至不再在所有表中使用审核字段了吗？我 没有看到很多人问这个问题，Microsoft 绝对不会让他们使用新的身份系统变得容易 和自定义审核字段。

是的，人们会这样做！一直以来！如果您存储的数据可由最终用户（无论他们是否在您的公司中）以任何方式编辑，请对其进行审核。总是。我想说的是，所有企业都会极端地审计东西（他们确实如此），但我甚至在我自己的个人项目中这样做。指标非常重要！

要记住的一件重要事情是，仅仅因为人们没有在StackOverflow或其他网站上询问它并不意味着它在我们的行业中不普遍和关键。

我应该在我的创建者字段中存储用户名或 ID。有人说 这可能是偏好，但我真的很想知道什么方向 Microsoft可能会推动新的身份

Microsoft（及其标识框架背后的团队）在为我们提供安全且强大的安全框架方面做得很好。也许他们会推荐他们解决这个问题的方法，但他们的框架并不是真正要解决这些细微差别（这些细微差别可能并且将因系统而异）。在一天结束时，选择适合数据库架构的模式。我认为大多数情况下用户名适合存储（如果它在您的系统中是唯一的）。毕竟，它们都代表相同的信息（除非您的用户名不是唯一的，这引发了进一步的问题）。

我真的只是想知道一个好的模式，当 使用 EF 在保存和检索用户时处理审核 并将其设置为需要它的实体上的导航属性 从数据库中提取记录时。

事实并非如此，而且很可能永远不会担心 EF 会帮助您解决此类问题。对不起，事情就是这样。每个应用程序都是独一无二的，EF（或任何其他ORM）不能满足每个人的需求。

我意识到所有这些都不能真正为您提供具体的答案，但我不得不放弃一些建议。

相关文章：