В чем разница в использовании UserStore и UserManager в Asp.Net Identtity?

22

Я очень новичок в Asp.Net Identity, и, пожалуйста, потерпите меня, если этот вопрос кажется глупым. Итак, когда я читаю определение для класса UserStore и класса UserManager на веб-сайте Microsoft, которые находятся по ссылкам ниже, это выглядит так, как оба класса определяют операции с пользователями (например, Add, Find, Delete и Modify). Так, когда я использую один по другому?:

Ссылка Ссылка

    
задан MinhNguyen 09.07.2015 в 08:48
источник
  • В терминах Driven Driven Design Usermanager - это уровень приложения, он координирует действие другого уровня, а userStorer - это уровень репозитория, он взаимодействует с базой данных, теперь предположим, что вы хотите отправить sms пользователю, вы не можете использовать userStore, поскольку его ответственность просто для выполнения задачи сохранения данных. но вы можете использовать userManager для отправки sms или другого действия. –  Arash 18.04.2016 в 12:19
  • Не нужно предисловие к вашему вопросу с извинениями. Если ваш вопрос уже задан, он обязательно будет отмечен как таковой. Некоторые из «самых глупых» вопросов наиболее проголосовали: переполнение стека: помощь одному миллиону разработчиков выйти из Vim –  daviesdoesit 25.09.2018 в 15:49

3 ответа

36

Там все довольно сложно и могло бы быть проще.

UserManger - это ... менеджер. Это на самом деле не взаимодействует с хранилищем, базой данных. Это то, что делает UserStore .

На самом деле UserManager имеет Конструктор , для которого требуется хранилище UserStore.

Зачем вам нужен другой объект для управления пользователями? Ну, главная причина в том, что вы можете отказаться от использования EF и создать свой собственный пользовательский магазин.

Все становится яснее, когда вы пытаетесь реализовать свой собственный поставщик услуг хранения. Я сделал это, и мой код можно загрузить с github .

Это UserManager . Как видите, там не так много. Всего несколько строк кода для настройки валидатора.

UserStore , напротив, довольно большой. В этом примере я реализовал несколько интерфейсов и переопределил несколько методов. Это то, что вы бы сделали, если хотите настроить взаимодействие с базой данных и / или расширить свои классы.

Обычно вы не взаимодействуете с UserStore , и фактически он скрыт. Вы просто создаете его и передаете в UserManager и ... забудете об этом.

Вы всегда можете настроить свой UserManager и открыть хранилище UserStore:

public class UserManager : UserManager<User, int>
{
    public UserManager(IUserStore<User, int> store): base(store)
    {
        this.Store = store;
    }

    public IUserStore<User, int> Store { get; set; }

}

и, возможно, оверидировать некоторые методы:

public class UserManager : UserManager<User, int>
{
    public UserManager(IUserStore<User, int> store): base(store)
    {
        this.Store = store;
    }

    public IUserStore<User, int> Store { get; set; }

    public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
    {
        return base.CreateAsync(user);
    }
}

но это было бы бессмысленно, если бы вам не пришлось выполнять какую-то особенную настройку.

Допустим, вы хотите создать пользователя, используя магазин вместо менеджера. Вы можете сделать что-то вроде этого:

await this.UserManager.Store.CreateAsync(new Custom.Identity.User() { UserName = "LeftyX" });

и это будет работать.

В приведенном выше классе, как вы можете видеть, я переопределил CreateAsync в UserManager.
Этот метод вызывает UserStore.CreateAsync() , и фактически вы должны вызвать базовый метод CreateAsync:

public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
   {
       return base.CreateAsync(user);
   }

Если вы этого не сделаете и, например, вместо этого вернете ноль, UserStore.CreateAsync не будет вызван и пользователь не будет создан.

Это имеет смысл в конце.

Полагаю, что лучший способ понять, как работает этот фреймворк, - это попробовать и настроить / реализовать ваше решение с вашим собственным хранилищем и посмотреть, как все классы взаимодействуют друг с другом.

Пример проекта не взаимодействует с базой данных, но использует хранилище json. Это очень легко отлаживать. Попробуйте, и в какой-то момент все станет яснее.

    
ответ дан LeftyX 09.07.2015 в 18:05
  • Большое спасибо, у меня есть более четкое понимание моего вопроса. Но в ваших классах вы ставите все методы в класс UserStore. но, согласно веб-сайту MS, у них есть методы для операций с пользователем в UserStore и UserManager. Это разные методы, но почему они просто не помещают все в UserStore или UserManager, как ваш? Какова их цель для этого? –  MinhNguyen 09.07.2015 в 19:21
  • Upvote для получения более четкого ответа, чем мой долговязый ответ. –  Adam 09.07.2015 в 19:39
  • @Adam: Спасибо. Оценил. –  LeftyX 09.07.2015 в 19:55
  • @MinhNguyen: Как я уже сказал, UserStore приводит к тому, что некоторые люди хотят реализовать своих провайдеров вместо EF. Это не раскрыто. Вы не можете настроить UserManager для изменения поставщика данных. Вы просто не можете. Вам необходимо реализовать свой UserStore. UserStore - это хранилище, как в DDD. –  LeftyX 09.07.2015 в 21:39
  • Store = Репозиторий / Менеджер = Служба –  Rod 12.01.2016 в 13:43
Показать остальные комментарии
3

Идентичность основана на двух основных блоках в ASP.NET Identity. Есть менеджер аутентификации, который принимает форму класса UserManager<T> . Также есть менеджер магазина, который является экземпляром UserStore<T> .

разница?

Объект UserStore<T> внедряется в диспетчер аутентификации, который используется для идентификации и аутентификации идентичности UserStore<T> . Ссылка UserManager<T> действует как аутентификатор для идентичности UserStore<T> .

Важные сведения

ASP.NET Identity основан на новейшем Open Web Interface. Это означает, что [как правило], интерфейс IAuthenticationManager, объявленный в Microsoft.Owin.Security : Связанный здесь , аутентификатор внедряется в класс и контроллер UserManager и, в основном, в каждую операцию, которая включает этап аутентификации.

В следующем:

private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
    var identity = await UserManager.CreateIdentityAsync(user,
    DefaultAuthenticationTypes.ApplicationCookie);
    AuthenticationManager.SignIn(new AuthenticationProperties() {
    IsPersistent = isPersistent }, identity);
}

Мы можем заметить, что менеджер аутентификации UserManager используется для проверки пользователя приложения " UserStore " на предмет идентификации менеджера аутентификации. Фрагмент, взятый из блога.

Заключение UserManager - это, по сути, логика домена вашего удостоверения ASP.NET. Контроллер, который вы используете для обработки «логина» или «идентификации», передается UserStore , который как MSDN: хранилище пользователей показывает ...

Represents an Entity Framework implementation of a user store that supports IUserStore, IUserLoginStore, IUserClaimStore and IUserRoleStore.

Как только UserStore имеет все необходимые поля, которые должны быть квалифицированы как личность, и вы квалифицировали UserManager как менеджер аутентификации и метод хранения контекста ... aka IdentityDbContext или какой-либо другой метод сохраняя значения в SQL (если он используется), у вас будет система идентификации, способная поддерживать логины.

    
ответ дан Adam 09.07.2015 в 17:03
  • Это все еще путало меня. Это мое понимание: для реализации операций с пользователями UserManager делает это на объекте UserStore. Основной целью UserStore является получение коллекции пользователей. Итак, почему мы не оставляем все операции (методы) только в классе UseManager? В чем разница между методами (add, delete ...) в UserStore и UserManaer? –  MinhNguyen 09.07.2015 в 17:32
  • Методы отличаются между классами? Они имеют одно и то же имя, но одно добавляет или удаляет претензию к пользователю, другое добавляет или удаляет заявку пользователей из «коллекции» аутентификации, –  Adam 09.07.2015 в 18:04
2

Я смотрел учебник по идентификации на YouTube, и я думаю, что этот скриншот может помочь:

Итак, UserManager - это фактический класс, с которым вам следует работать, но он не знает, как хранить и извлекать данные из базы данных. он даже не знает, куда поступают и откуда поступают данные.

Для этих вещей он использует UserStore и говорит ему, например: «Эй, UserStore, у меня есть новый пользователь, которого нужно сохранить для будущего использования, я не знаю, где вы собираетесь его сохранить и как вы собираюсь сделать это, просто сохрани это для меня "

Затем UserStore выполняет реальную работу, например, где должны быть сохранены данные? какая база данных? и как? по умолчанию используется EF и SQL Server, поэтому, если вы хотите использовать какую-то другую базу данных, например MySQL, вам потребуется другой UserStore.

Это одна из функций, которые были добавлены в Identity по сравнению с членством, которое работало только с SQL Server.

То же самое относится и к RoleManager и RoleStore.

    
ответ дан Sasan 10.08.2017 в 12:10