为什么 ASP.NET Identity 的“UserStore”中有这么多存储库？答案

【问题标题】：Why so many repositories in ASP.NET Identity's `UserStore`?为什么 ASP.NET Identity 的“UserStore”中有这么多存储库？
【发布时间】：2016-03-20 06:00:17
【问题描述】：

我即将将 Identity 的 Microsoft.AspNet.Identity.EntityFramework 项目 (v 2.0.0.0) 转换为使用 NHibernate 作为其持久性机器的项目。我的第一个“绊脚石”是UserStore 类中的这组存储库：

private readonly IDbSet<TUserLogin> _logins;
private readonly EntityStore<TRole> _roleStore;
private readonly IDbSet<TUserClaim> _userClaims;
private readonly IDbSet<TUserRole> _userRoles;
private EntityStore<TUser> _userStore;

类型参数TUser 被限制为IdentityUser<TKey, TUserLogin, TUserRole, TUserClaim>，并且这个类型有自己类似的集合：

public virtual ICollection<TRole> Roles { get; private set; }
public virtual ICollection<TClaim> Claims { get; private set; }
public virtual ICollection<TLogin> Logins { get; private set; }

如果我只需要管理TUser 的一个存储库，我的生活会轻松得多，因为这些用户中的每一个都已经在处理自己的事情了。有什么重要的原因我不能仅仅取消这些（为了取消对实体框架的任何依赖，比如DbSet？

我可以设计自己的存储库类来代替 DbSet 以符合 UserStore 的这种设计，但我更愿意只是丢失它们并让每个用户实例处理自己的声明等。

【问题讨论】：

有许多将其他数据库技术与 Identity Framework 结合使用的示例。英孚只是提供者之一。例如，已经有 4 个现有的 nHibernate 示例，请参阅：nuget.org/… - 此外，其中一些还有源代码。例如：github.com/MatthewRudolph/Airy
我为 HNibernate 找到的第一个，最突出的项目迫使我在一个完全通用的系统中使用字符串键，这是我认为不可接受的标准，我的任务是使用我们现有的 NHibernate 自定义 DAL为了身份的持久性，所以我觉得最好，也最有趣，做自己。当然，我会查看您引用的示例以获取灵感，谢谢。

标签： c# asp.net entity-framework nhibernate asp.net-identity

【解决方案1】：

额外的DbSet 类用于保存与用户声明、角色和登录相关的数据，而ICollection 字段是允许您通过当前选择的用户从这些表中读取数据的导航属性。

如果您要对 Identity 框架进行全面转换（上帝保佑您），您将需要这些数据库实体来管理这些数据。

但是，您可以拥有一个 User 存储库，该存储库公开对其声明、角色和登录名的访问权限，以使其更简单一些。

【讨论】：

我想知道为什么他们一开始不使用那个单用户存储库。 “祝你好运” - 谢谢，这是一项非常有趣且具有挑战性的任务，因为这是我第一次在 Identity 内部工作，也是我第一次使用 NHibernate。
你的意思是UserStore？我认为这更像是一个服务类，而不是一个用于公开处理所有用户信息的方法的存储库。
我的意思是为什么他们在UserStore 中没有一个用户存储库，因为他们已经有一个基于DbSet 的用户存储库EntityStore<TUser>，而在EF 中，加载和保存用户关联的集合都可以由DbContext 和DbSet 处理，那么为什么他们还必须为所有用户对象集合提供“存储库”？
因为UserClaim、UserLogin 和UserRole 是三个不同的实体，它们具有三个不同的关注点，彼此并不真正相关。如果你问微软为什么不把它们合二为一，那么我不是要问的人。
我实际上是在问为什么 MS 不只是让用户存储库也坚持说那些作为 User 实体的一部分存在的对象。但这已经足够了，我现在就试着按照“我的方式”来做，看看效果如何。谢谢。