asp.net-mvc - ASP.NET MVC 身份默认实现

Question

VS 2013 中带有“个人用户帐户”的默认 Wep 应用程序附带一个帐户 Controller ，其代码如下:

    public AccountController(ApplicationUserManager userManager, ApplicationSignInManager signInManager )
    {
        UserManager = userManager;
        SignInManager = signInManager;
    }

    private ApplicationUserManager _userManager;

    public ApplicationUserManager UserManager
    {
        get
        {
            return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
        }
        private set
        {
            _userManager = value;
        }
    }

以及 Startup.Auth.cs 中的这一行

app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);

我想了解什么机制将 userManager 参数传递给构造函数。我相信这里使用了依赖注入(inject)模式。如果我是正确的，在 Visual Studio 解决方案中的哪里可以找到负责依赖项注入(inject)的代码？

接下来是UserManager部分，如果_userManager已经在 Controller 中设置了，为什么我们要测试它是否为null？

Answer 1

您已经找到了负责执行依赖项注入(inject)的代码。 app.CreatePerOwinContext() 是在 Owin 管道中注册 usermanager(创建 usermanager 的委托(delegate))的代码，它实际上只是一个保存在 HttpContext 中的字典>。

您可以在 blogpost 中深入阅读该机制的工作原理。 .

关于你的另一个问题我完全理解!如果注入(inject)了依赖项，为什么要检查 null...？嗯:那是因为 Owin 在这里被用作穷人的 DI 机制，而您在默认项目模板中看到的实际上是一个后备机制，带有 service locator anti pattern 的味道。 。由于使用 Owin 而不是像样的 DI 容器，因此 MVC 管道需要默认构造函数，因此需要检查 null 和服务定位器。我不清楚 MVC 如何决定使用哪个构造函数。但我发现 usermanager 有时会被注入(inject)，并且在其他场景中将为空。可能是因为 owin 上下文大多数时候仅在创建帐户 Controller 后才可用。

虽然该模板开箱即用，但它确实让我感到惊讶，就像它让你感到惊讶一样。因此，我干净地实现了一个像样的 DI 容器，并删除了大部分 owin 服务定位器内容。

如果您有兴趣可以找到我的解决方案 here我在哪里使用Simple Injector 。还有其他DI容器的解决方案here