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

Question

我即将将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,因为每个用户都已经处理好自己的东西.是否有任何重要的原因我不能废除这些(为了消除对Entity Framework的任何依赖,比如DbSet？

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

Answer 1

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

如果您要完全转换身份框架(以及上帝速度给您),您将需要这些数据库实体来管理这些数据.

但是,您可以使用单个User存储库来公开对其声明,角色和登录的访问,以使其更简单一些.