为什么 ASP.NET Identity 的 `UserStore` 中有这么多存储库？

Question

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

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 的一个存储库，我的生活就会轻松得多，因为这些用户中的每一个都已经处理了他们自己的东西。有什么重要的原因我不能只取消这些（为了取消对 Entity Framework 的任何依赖，比如 DbSet?

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

Answer 1

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

如果您要完全转换 Identity 框架（并且速度很快），您将需要这些数据库实体来管理这些数据。

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