Почему так много репозиториев в ASP.NET Identity `UserStore`?
Я собираюсь преобразовать проект 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, но я бы предпочел просто потерять их и позволить каждому экземпляру пользователя заботиться о своих собственных претензиях и т.д.
Ответы
Ответ 1
Дополнительные классы DbSet предназначены для сохранения данных, связанных с требованиями пользователя, ролями и входами, а поля ICollection - это свойства навигации, которые позволяют вам считывать данные из этих таблиц через выбранного вами пользователя.
Если вы собираетесь полностью преобразовать структуру Identity (и скорость бота к вам), вам понадобятся эти объекты базы данных для управления этими данными.
Однако у вас может быть единственный репозиторий User, который предоставляет доступ к их утверждениям, ролям и входам, чтобы сделать его немного проще.
