ASp.net identity 2.0 samples - controller constructors, re-use of DB constructor and Owin middleware

Question

I have installed the asp.net identity 2.0 samples from the link referenced here:

http://blogs.msdn.com/b/webdev/archive/2014/03/20/test-announcing-rtm-of-asp-net-identity-2-0-0.aspx

and have a few specific questions about the samples, and best practice. I realise the samples are beta, so this may explain some of my concerns\questions.

1) Why do most of the controller constructors e.g. AccountController take instances of the UserManager class in their constructor. There is no DI in place that i can see, and the controllers also have a public property of type UserManager which get a cached instance of this from the Owin Context. Is this simply a product of (bad) scaffolding) or am i missing some subtle DI?

2) I wish to augment the ApplicationUser and ApplicationDBContext with additional application specific data. To get a copy of the current ApplicationDBContext class, it looks like i have to get the current Owin context, and then get a copy of the ApplicationDBContext from that. Is this correct? I was thinking of creating base controller class with a ApplicationDBContext property and UserManager properties which follow the pattern demonstrated in the AccountController and then inherit the controllers that need these properties from that.

3) Is the implicit assumption that every HTTP request needs an applicationdbcontext a valid one? Isn't this wasteful?

4) Finally, i wish to add an ApprovedByAdmin property which only allows the user to login if their registration has been approved by an admin. I envisage adding this to applicationuser. Based on the samples of the Login method, checks against the various properties are done via the UserManager class e.g.

UserManager.IsLockedOutAsync(user.Id))
UserManager.CheckPasswordAsync(user, password))

I'm not sure why each of these are done as separate async calls, but since i cannot modify UserManager, will i have to do something like:

var user = await UserManager.FindByNameAsync(userName);

if(!user.ApprovedByAdmin)
{
    ....
}

I think that's all of my questions for now!

Answer 1

1. The AccountControllers take the UserManagers so its testable, and easy to DI if desired
2. Yes you should get the ApplicationDbContext from the OwinContext, there should only be one DbContext per request.
3. The cookiemiddleware by default needs to have a db context to validate that the identity cookie is valid, so its needed. Also creating a db context doesn't add very much overhead unless until methods that hit the database are actually used.
4. What you are doing off the user itself is fine. In general you could extend UserManager with an ApplicationUserManager, but you only want to do this if you wanted the flexibility to swap out UserStores without changing your app code. Typically this only affects things like writing LINQ queries using navigation properties on poco classes which relies on EF specific lazy loading functionality to work.