如何在UserManager和UserStore中使用DI [英] How to use DI with UserManager and UserStore

问题描述

给出一个MVC控制器构造函数的典型设置，该构造函数将UserManager(需要UserStore)传递给其父类，如何将其转换为通过IoC注入?

Given a typical setup of a MVC controller constructor passing UserManager (which takes UserStore) to it's parent class, how would this be converted to be injected via IoC?

从此开始:

public AccountController()
    : this(new UserManager<ApplicationUser>(
        new UserStore<ApplicationUser>(new ApplicationDbContext())))
{
}

我会这样想:

public AccountController(IUserStore store)
    : this(new UserManager<ApplicationUser>(store)))
{
}

尽管这样做的确会丢失IdentityDbContext.

Though this does, of course, lose the IdentityDbContext.

应该如何设置IoC，如何定义构造函数以允许注入UserManager，UserStore和IdentityDbContext?

How should the IoC be setup and how should the constructor be defined to allow injection of the UserManager, UserStore and IdentityDbContext?

推荐答案

您需要创建一些类以简化注入.

You would need to create some classes to allow for easier injection.

让我们从UserStore开始.创建所需的接口并使其继承自IUserStore<ApplicationUser>

Let us start with the UserStore. Create the desired interface and have it inherit from IUserStore<ApplicationUser>

public IUserStore : IUserStore<ApplicationUser> { }

创建如下的实现.

public ApplicationUserStore : UserStore<ApplicationUser>, IUserSTore {
    public ApplicationUserStore(ApplicationDbContext dbContext)
        :base(dbContext) { }
}

然后可以在OP中根据需要完成UserManager.

The UserManager can then be done as desired in the OP.

public class ApplicationUserManager : UserManager<ApplicationUser> {

    public ApplicationUserManager(IUserSTore userStore) : base(userStore) { }

}

现在剩下的就是确保您决定使用哪个IoC容器注册必要的类.

SO now all that is left is to make sure that which ever IoC container you decide to use registers the necessary classes.

ApplicationDbContext --> ApplicationDbContext 
IUserStore --> ApplicationUserStore 

如果您想更进一步并抽象化UserManager，则只需创建一个暴露所需功能的界面

If you want to go a step further and abstract the UserManager then just create an interface that exposes the functionality you want

public interface IUserManager<TUser, TKey> : IDisposable
    where TUser : class, Microsoft.AspNet.Identity.IUser<TKey>
    where TKey : System.IEquatable<TKey> {
    //...include all the properties and methods to be exposed
    IQueryable<TUser> Users { get; }
    Task<TUser> FindByEmailAsync(string email);
    Task<TUser> FindByIdAsync(TKey userId);
    //...other code removed for brevity
}

public IUserManager<TUser> : IUserManager<TUser, string>
    where TUser : class, Microsoft.AspNet.Identity.IUser<string> { }

public IApplicationUserManager : IUserManager<ApplicationUser> { }

让您的经理从中继承.

public class ApplicationUserManager : UserManager<ApplicationUser>, IApplicationUserManager {

    public ApplicationUserManager(IUserSTore userStore) : base(userStore) { }

}

这现在意味着Controller现在可以依赖抽象而不依赖于实现问题

This now means that the Controller can now depend on an abstraction and not on implementation concerns

private readonly IApplicationUserManager userManager;

public AccountController(IApplicationUserManager userManager) {
    this.userManager = userManager;
}

再次在IoC容器中向实现注册接口.

And again you register the interface with the implementation in the IoC container.

IApplicationUserManager  --> ApplicationUserManager 

更新:

如果您喜欢冒险并且想要抽象身份框架本身，请查看此处给出的答案

If you are feeling adventurous and want to abstract identity framework itself take a look at the answer given here

这篇关于如何在UserManager和UserStore中使用DI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！