Какова цель методов UserManager, таких как GetPhoneNumberAsyn c (пользователь IdentityUser), когда требуемые свойства могут быть получены из объекта пользователя?

Question

Я пытаюсь понять некоторые логики c за представлениями ASP. Net Core Identity UI.

Например, Account \ Manage \ Index.cs html. cs содержит следующий код:

    private async Task LoadAsync(IdentityUser user)
    {
        var userName = await _userManager.GetUserNameAsync(user);
        var phoneNumber = await _userManager.GetPhoneNumberAsync(user);

        Username = userName;

        Input = new InputModel
        {
            PhoneNumber = phoneNumber
        };
    }

Почему выполняется вызов _userManager.GetPhoneNumberAsyn c (пользователь), когда мы можем просто извлечь свойство PhoneNumber непосредственно из объекта пользователя?

Answer 1

Тот факт, что настройка идентификатора по умолчанию состоит из объекта, сопоставленного с базой данных Entity Framework, является деталью реализации, которая не заботит менеджер пользователя. Диспетчер пользователей фактически реализован таким образом, что он действует в основном как фасад для различных отдельных компонентов, которые предоставляют такие функции, как проверка пароля, хеширование и т. Д. c.

Один из этих компонентов это IUserStore<>, который отвечает за фактическое сохранение объекта идентификации каким-либо образом.

Реализация по умолчанию - UserStore<> в Microsoft.AspNetCore.Identity.EntityFrameworkCore. Обратите внимание, что пространство имен включает EntityFrameworkCore, так что это единственное, что фактически указывает c на то, как пользовательский объект сохраняется: Использование EF Core.

Общее IUserStore<> отвечает только за фактическое сохранение и сохранение объекта пользователя. Однако для реализации магазина возможно включить дополнительные функции, такие как поддержка телефонных номеров, через различные интерфейсы флагов функций. Например, IUserClaimStore<>, IUserEmailStore<>, IUserPhoneNumberStore<> или IUserTwoFactorStore<>. Это то, что все высокоуровневые методы в диспетчере пользователей будут go, чтобы определить (а) поддержку этих функций и (б), как получить эти значения.

Так что этот дизайн Диспетчер пользователей кажется сложным, если вы думаете о пользователях только как о сущностях, которые сохраняются в вашем ORM, но на самом деле он позволяет менять всю архитектуру за диспетчером пользователей, не затрагивая ее спереди. Вот почему интерфейс Identity UI по умолчанию использует эти методы, чтобы не полагаться на подробности реализации о том, что пользователь является сущностью, и вместо этого go через диспетчер пользователей для получения необходимых значений.

это имеет значение для вашего приложения? Возможно нет. Если вы решите использовать хранилище пользователей по умолчанию с IdentityUser, то вы можете просто получить доступ к свойствам напрямую. Маловероятно, что приложения полностью отключат все это позже, и вам, вероятно, придется также вносить другие изменения. Таким образом, для кода приложения вы можете просто получить доступ к свойствам объекта напрямую.