MVC 5: Должен ли я наследовать моего пользователя из класса IdentityUser?

Я пытался узнать Identity Asp.Net и в этом учебнике,

Создание модели Entity Framework First ToDo в моделях \AppModels, cs part MyUser class наследует от класса IdentityUser и MyDbContext наследует от класса IdentityDbContext<MyUser>. Почему это?

Скажем, у меня есть класс User, который содержит всю информацию пользователя моего веб-приложения, должен ли этот класс наследовать от IdentityUser и должен ли мой DbContext наследовать от IdentityDbContext<User>?

Кроме того, каковы преимущества наследования класса dbcontext от IdentityDbContext<TClass> по классу plain DbContext, как это сделано в MVC 4

Ответ 1

ASP.Net MVC 5.0 использует реализацию OWIN для подключи и играй.

Существует несколько интерфейсов, разработанных для этого

FROM Scott Allen Article

IUser

Пользовательский объект должен реализовать интерфейс IUser, который требует каждого пользователь должен иметь хотя бы ID и имя. Наиболее заметный аспект IUser - это свойство Id типа string. Строки хорошо работают для GUID но может быть немного сложнее при использовании целых чисел для ключей, как это обычно бывает при использовании SQL Server. Подробнее в следующей статье.

IUserStore

Интерфейсы я * Store в сборке Core Identity учитывают различные уровни функциональности.

IUserStore определяет минимальную функциональность, которую вы хотите для пользователей - создавать, извлекать, обновлять и удалять (CRUD). Если ваш сайт хочет разрешить пользователям создавать локальные учетные записи с паролями, вам понадобится компонент, реализующий IUserPasswordStore (который является IUserStore). Для сторонних пользователей (Twitter и Facebook, для пример), добавьте в IUserLoginStore, и для хранения претензий есть IUserClaimStore. Кроме того, не показано на диаграмме классов выше, является сбор интерфейсов для ролей (IRole, IUserRoleStore и т.д.). Позволять начнутся дебаты о ролях и заявлениях.

UserManager

UserManager - это конкретный класс, и UserManager предоставляет логику домена для работы с пользовательской информацией. UserManager знает, когда указывать пароль, когда проверять пользователя и как обрабатывать претензии.

В UserManager имеется несколько точек расширяемости, например, у менеджера есть ряд свойств, которые вы можете использовать для установки пользовательского валидатора пользователя (любой объект, реализующий IIdentityValidator), пользовательский пароль для проверки подлинности и пользовательский пароль. Основная точка расширяемости - через конструктор UserManager, который позволяет передавать любой объект, реализующий IUserStore. Если вы хотите использовать UserManager для управления пользовательской информацией, хранящейся на SQL Server, посмотрите на предварительно созданные классы, чтобы сделать это в более поздней публикации, но также легко создать IUserStore для работы с базой данных документа или другими формами хранения.

Помните, что IUserStore не знает, как работать с паролями пользователей, только IUserPasswordStore знает о паролях. UserManager знает о различных основных интерфейсах и будет пытаться работать с возможностями объекта store, указанного в конструкторе. Например, если вы используете FindByIdAsync, UserManager может использовать хранилище пользователей для запроса пользователя по идентификатору, но если вы вызываете FindAsync (который принимает имя пользователя и пароль), а основной магазин не реализует интерфейс хранилища IUserPassword, UserManager будет вынуждено исключить исключение.

Его сложно использовать один конкретный класс для всего: от пользователей до паролей к претензиям, а также компромиссы. Ну, а также посмотрите на некоторые компромиссы на предстоящих постов.

РЕДАКТИРОВАТЬ: Отъезд Реализация ASP.Net Identity

Теперь идентификатор ASP.Net поддерживает общий IdentityUser<TKey> до того, как он был строкой, то есть UserId был строкой

Ответ 2

Класс IdentityDbContext < > - это класс, который наследует от DbContext, как обычно, но предоставляет готовые DbSets для ролей и пользователей.

Смотрите класс doc: http://msdn.microsoft.com/en-us/library/microsoft.aspnet.identity.entityframework.identitydbcontext%28v=vs.111%29.aspx

Да, ваш пользовательский dto должен наследовать от IdentityUser, и любые дополнительные поля, которые вы хотите в своей базе данных, связанные с вашим пользователем, могут быть добавлены в этот класс.

Это упрощает добавление дополнительных полей в вашу базу данных, которые связаны с вашим пользователем, и если вы используете инициализацию Entity Framework и инициализацию базы данных, это означает, что теперь вы можете создать всю базу данных Identity из своего DbContext.