Why so many repositories in ASP.NET Identity's `UserStore`?

Question

I am about to undertake a conversion of Identity's Microsoft.AspNet.Identity.EntityFramework project (v 2.0.0.0) to one that uses NHibernate as its persistence machine. My first 'stumbling block' is this set of repositories in the 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;

Type parameter TUser is constrained to IdentityUser<TKey, TUserLogin, TUserRole, TUserClaim>, and this type has its own similar set of collections:

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

My life would be much easier if I had to manage just one repository, of TUser, as each of these users already take care of their own stuff. Is there any important reason I can't just do away with these (in order to do away with any dependencies on Entity Framework, like DbSet?

I could contrive my own repository class in place of DbSet to conform to this design of UserStore, but I would much prefer to just lose them and let each user instance take care of its own claims etc.

Answer 1

The additional DbSet classes are for persisting data related to a user's claims, roles and logins, while the ICollection fields are the navigation properties that allow you to read the data from these tables through your currently selected user.

If you are going for a full conversion of the Identity framework (and god speed to you), you will need these database entities to manage this data.

You could, however, have a single User repository that exposes access to their claims, roles and logins to make it a little simpler.