我已经从这里引用的链接安装了asp.net identity 2.0示例:
http://blogs.msdn.com/b/webdev/archive/2014/03/20/test宣布- rtm的asp -网-认同- 2 - 0 - 0. - aspx
并对样本和最佳实践有一些具体的问题。我意识到样本是测试版的，所以这可能解释了我的一些担忧问题。
1)为什么大多数控制器构造函数(例如AccountController)在其构造函数中使用UserManager类的实例?我可以看到没有DI，控制器也有一个UserManager类型的公共属性，它从Owin上下文中获得这个的缓存实例。这是一个简单的产品(坏)脚手架)还是我错过了一些微妙的DI?
2)我希望用附加的特定于应用程序的数据来扩展ApplicationUser和ApplicationDBContext。要获得当前ApplicationDBContext类的副本，看起来我必须获得当前Owin上下文，然后从中获得ApplicationDBContext的副本。这是正确的吗?我正在考虑创建具有ApplicationDBContext属性和UserManager属性的基控制器类，它们遵循AccountController中演示的模式，然后继承需要这些属性的控制器。
3)每个HTTP请求都需要一个applicationdbcontext的隐含假设是有效的吗?这不是很浪费吗?
4)最后，我希望添加一个ApprovedByAdmin属性，它只允许用户登录，如果他们的注册已被管理员批准。我设想将此添加到applicationuser。根据Login方法的示例，检查各种属性是通过UserManager类完成的，例如
UserManager.IsLockedOutAsync(user.Id))
UserManager.CheckPasswordAsync(user, password))
我不知道为什么这些都是作为单独的异步调用完成的，但是因为我不能修改UserManager，我必须这样做:
var user = await UserManager.FindByNameAsync(userName);
if(!user.ApprovedByAdmin)
{
....
}
- AccountControllers采用usermanager，所以它是可测试的，并且很容易DI如果需要
- 是的，你应该从OwinContext中获得ApplicationDbContext，每个请求应该只有一个DbContext。
- 默认情况下，cookiemidleware需要有一个db上下文来验证身份cookie是否有效，所以它是必需的。此外，创建db上下文不会增加太多的开销，除非实际使用击中数据库的方法。
- 你所做的用户本身是好的。一般来说，你可以用ApplicationUserManager扩展UserManager，但只有当你想灵活地替换UserStores而不改变你的应用程序代码时，你才想这样做。通常情况下，这只会影响到在poco类上使用导航属性编写LINQ查询，这依赖于EF特定的延迟加载功能来工作。