我正在使用最新的MVC6和Entity Framework 7,但我相信MVC5和Entity Framework 6中使用的许多技术也可以帮助回答我的问题。
我的数据库中几乎所有表都有以下4个用于审计的字段:CreatedDate,CreatedBy,ModifiedDate,ModifiedBy。
我想确定在将项目保存到数据库时,我应该在CreatedBy字段中存储内置的IdentityUser(AspNetUsers表)中的哪个字段。
我开始尝试使用“用户名”,因为通过调用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);
但后来我注意到Entity Framework在尝试添加迁移和创建数据库时大叫,因为Username需要设置为主键,或者它不能用作另一个表中的外键。
然后我到了我想我会使用GUID的实际Id的地步。这种技术的问题在于,当尝试保存时,当前登录用户的ID不容易获得:'User.Identity.Name'就是那里。
以下是一些问题,我希望有EF和审核经验的人尝试为我解答:
人们甚至在他们所有的表中都使用审计字段吗?我没有看到很多其他人提出有关此问题的问题,微软绝对不会轻易使用他们的新身份系统和自定义审计字段。
我应该在CreatedBy字段中存储用户名或ID。有人说这可能是偏好,但我真的想知道微软可能会推动使用新身份的方向。存储Id的问题是在保存时很难得到它,存储用户名的问题在于它不是AspNetUsers表中的主键。
我真的只想知道一个好的模式,当使用EF在保存时处理审计,并检索用户并将其设置为我需要它的实体上的导航属性时从中提取记录数据库中。
答案 0 :(得分:1)
我试图弄清楚内置的IdentityUser中的哪个字段 (AspNetUsers表)我应该存储在CreatedBy字段中 将项目保存到数据库。
使用该网站的人的用户名(在Thread.CurrentPrincipal
上,通过User.Identity.Name
在ASP.Net中访问)。还有谁?
是使用您网站的当前经过身份验证的用户的身份,这是您应该在审核表中添加的内容。
人们甚至在他们所有的桌子上都使用审计字段吗?一世 没有看到很多人提出有关此事和微软的问题 绝对不容易使用他们的新身份系统 和自定义审计字段。
是,人们做到了!每时每刻!如果您要存储可由最终用户以任何方式编辑的数据(无论他们是否在您的公司中),请对其进行审核。总是。我要说的是,所有企业都在极端地审核(他们确实如此),但我甚至在我自己的个人项目中这样做。度量标准非常重要!
要记住的一件重要事情是,仅仅因为人们在StackOverflow或其他网站上没有询问它并不意味着它在我们的行业中并不流行和关键强>
我应该在CreatedBy字段中存储用户名或ID。有人说 这可能是偏好,但我真的想知道方向 微软可能会推出新的身份
Microsoft(以及他们身份框架背后的团队)在为我们提供安全可靠的安全框架方面做得非常出色。也许他们会推荐他们解决这个问题的方法,但他们的框架并不是真正意味着要解决这些细微差别(这些细微差异可能会因系统而异)。在一天结束时,选择适合您的数据库架构的那个。我认为大多数时候用户名适合存储(如果它在您的系统中是唯一的)。毕竟,它们都代表相同的信息(除非你的用户名不是唯一的,这引发了更多的问题)。
我真的只想知道一般的好模式 使用EF在保存和检索用户时处理审计 并将其设置为我需要它的实体的导航属性 从数据库中提取记录时。
事实并非如此,并且很可能永远不会让EF担心这样的事情。对不起,这就是它的方式。每个应用程序都是独一无二的,EF(或任何其他ORM)无法满足每个人的需求。
我意识到所有这些并没有真正为你提供具体的答案,但我不得不放弃一些建议。