为什么 ASP.NET 身份的"用户存储"中有这么多存储库？

Question

我即将将Identity的Microsoft.AspNet.Identity.EntityFramework项目（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的设计，但我更愿意放弃它们，让每个用户实例处理自己的声明等。

Answer 1

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

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

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