AspNetUsermanager 和 UserManager 的区别

Question

NB 我收到警告说有很多类似的问题可用。但是，这些主要是关于其他概念，例如 (and also, difference between a bunch of unrelated things，所以我猜测 Stacky 权重在 差异 中同样）。然而，谷歌搜索 difference AspNetUserManager UserManager 产生了很多关于如何设置安全性的指南，但没有讨论实际差异。

所以，我去了古老的 MSDN 并查找了那两个 类。显然，AspNetUsermanager是这样描述的。

Provides the APIs for managing user in a persistence store.

而且，虽然 UserManager 是这样描述的。

Provides the APIs for managing user in a persistence store.

鉴于两者都用于管理用户，人们会期望两者在功能上有一定的重叠。但是，我觉得 reader 应该在真实的表述中有更多变化。

我的问题是 - 它们之间有什么关系（即在什么情况下前者优于后者）？

Answer 1

如果我检查代码，唯一的区别是 AspNetUserManager<TUser> 从 httpcontext 获取（默认）取消令牌（根据请求中止）。我想这在取消请求时会提供更好的体验。所有其他方法和属性都继承自 UserManager<TUser>

/// <summary>
    /// Provides the APIs for managing user in a persistence store.
    /// </summary>
    /// <typeparam name="TUser">The type encapsulating a user.</typeparam>
    public class AspNetUserManager<TUser> : UserManager<TUser>, IDisposable where TUser : class
    {
        private readonly CancellationToken _cancel;

        /// <summary>
        /// Constructs a new instance of <see cref="AspNetUserManager{TUser}"/>.
        /// </summary>
        /// <param name="store">The persistence store the manager will operate over.</param>
        /// <param name="optionsAccessor">The accessor used to access the <see cref="IdentityOptions"/>.</param>
        /// <param name="passwordHasher">The password hashing implementation to use when saving passwords.</param>
        /// <param name="userValidators">A collection of <see cref="IUserValidator{TUser}"/> to validate users against.</param>
        /// <param name="passwordValidators">A collection of <see cref="IPasswordValidator{TUser}"/> to validate passwords against.</param>
        /// <param name="keyNormalizer">The <see cref="ILookupNormalizer"/> to use when generating index keys for users.</param>
        /// <param name="errors">The <see cref="IdentityErrorDescriber"/> used to provider error messages.</param>
        /// <param name="services">The <see cref="IServiceProvider"/> used to resolve services.</param>
        /// <param name="logger">The logger used to log messages, warnings and errors.</param>
        public AspNetUserManager(IUserStore<TUser> store,
            IOptions<IdentityOptions> optionsAccessor,
            IPasswordHasher<TUser> passwordHasher,
            IEnumerable<IUserValidator<TUser>> userValidators,
            IEnumerable<IPasswordValidator<TUser>> passwordValidators,
            ILookupNormalizer keyNormalizer,
            IdentityErrorDescriber errors,
            IServiceProvider services,
            ILogger<UserManager<TUser>> logger)
            : base(store, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer, errors, services, logger)
        {
            _cancel = services?.GetService<IHttpContextAccessor>()?.HttpContext?.RequestAborted ?? CancellationToken.None;
        }

        /// <summary>
        /// The cancellation token associated with the current HttpContext.RequestAborted or CancellationToken.None if unavailable.
        /// </summary>
        protected override CancellationToken CancellationToken => _cancel;
   }

来自https://github.com/dotnet/aspnetcore/blob/main/src/Identity/Core/src/AspNetUserManager.c

非常相关，有一个建议去掉这个class:

Consider adding optional cancellationToken to manager APIs

If we do this in 3.0, we could probably also get rid of the automatic HttpRequest.Aborted hookup, which would let us get rid of the derived AspNetUserManager entirely.

见https://github.com/dotnet/aspnetcore/issues/5763