ASP.NET MVC Identity Default Implementation

Question

The default Wep Application in VS 2013 with "Individual User Accounts" comes with an account controller with the following code :

    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;
        }
    }

and this line in Startup.Auth.cs

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

I'd like to understand what mechanism passes userManager parameter to the constructor. I believe dependendy injection pattern is used here. If I'm correct, where in the Visual Studio solution can I find the code responsible for dependency injection ?

Next for the UserManager part, why should we test if _userManager is null if it's been set up in the controller ?

Answer 1

You allready found the code responsible for doing the dependency injection. app.CreatePerOwinContext() is the code for registering the usermanager (a delegate to create the usermanager) in the Owin pipeline, which is actually just a dictionary which is saved in the HttpContext.

You can read in depth how this mechanism works in this blogpost.

Regarding your other question which I completely understand! Why check for null if the dependency is injected...? Well: That's because Owin is used here as a poor man's DI mechanism and what you see in the default project template is actually a fallback mechanism with a smell of the service locator anti pattern. Because Owin is used instead of a decent DI container the MVC pipeling needs a default constructor, and therefore a check for null and the service locator is necessary. How MVC decides which constructor to use is not clear to me. But I found that the usermanager sometimes got injected and will be null in other scenario's. Probably because the owin context is most of the time only available after the creation of the Account controller.

While the template works out-of-the-box it really moves my eyebrows, just as it moves yours. So I went with a clean implementation of a decent DI container and got the remove most of the owin service locator stuff.

If your interested you can find my solution here where I used Simple Injector. And there are solutions for other DI containers here