Microsoft.AspNet.Identity简介
Microsoft.AspNet.Identity是微软在MVC 5.0中新引入的一种membership框架,和之前ASP.NET传统的membership以及WebPage所带来的SimpleMembership(在MVC 4中使用)都有所不同。
Microsoft.AspNet.Identity是符合微软开放Owin标准里面Security标准的一种实现。且在MVC 5中默认使用EntityFramework作为Microsoft.AspNet.Identity的数据存储实现。
从Microsoft.AspNet.Identity里面,我们其实可以看出微软所采用的一种MVC的分层架构;或许这种分层架构我们可以学习并应用在自己的开发当中。
Microsoft.AspNet.Identity从Preview到RC到RTM一直都有变化,下面我当然以RTM的结构来简单讲解一下这种值得借鉴的参考分层架构。
参考分层架构
首先要说明的是,我上面提到的分层架构不是指MVC本身的分层,而是指Controller与Data之间的分层(与耦合方式)。
你在VS2013中创建一个带有独立账号管理的MVC项目后,默认就有一个用于登录、注册的AccountController,通过这个Controller,我们就可以顺藤摸瓜一窥Microsoft.AspNet.Identity的真容。
我们先来看一个类图:
从上图中,我们可以看到如下类以及他们的关系:
AccountController
账号管理的Controller。具有一个名为UserManager的属性,这个属性的类型为UserManager<TUser>。并暴露一个名为AuthenticationManager的属性,类型为IAuthenticationManager。
Controller顾名思义只起到控制器的作用,就是把M和V结合在一起,而如何得到M如何处理M得到什么样的M,就是业务逻辑的事情。
业务逻辑你可以很dirty的写中Controller里面,也可以像Microsoft.AspNet.Identity一样把用户管理的业务逻辑都封装到UserManager中。
把登录和注销逻辑保证到AuthenticationManager中,当然AuthenticationManager实际上是一个来自于Owin的接口IAuthenticationManager,通过这样的设定,Microsoft.AspNet.Identity就和Owin的Security兼容了。不过我这里不会详细讲Owin的Security的。
AccountController提供了两个构造方法:
- 一个默认的:
public AccountController() : this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()))) { }
- 一个可以传入UserManager实例的:
public AccountController(UserManager<ApplicationUser> userManager) { UserManager = userManager; }
UserManager<TUser>(Microsoft.AspNet.Identity,Microsoft.AspNet.Identity.Core.dll)
这些一个泛型的用户管理业务逻辑的类。泛型的原因是因为要支持Profile信息的扩展,这里也不详细介绍。UserManager<TUser>仅仅是封装了业务处理的逻辑,并没有去实现数据如何处理的代码。相关代码都交给IUserStore<TUser>。
UserManager<TUser>只提供了一个接受IUserStore<TUser>实例的构造函数:
public UserManager(IUserStore<TUser> store);
IUserStore<TUser>(Microsoft.AspNet.Identity,Microsoft.AspNet.Identity.Core.dll)
这个接口抽象了用户数据如何处理的逻辑。但是具体实现要交给和具体数据访问技术相关的实现。从AccountController的默认构造函数中,我们可以看到给UserManager传入了一个IUserStore<TUser>的实现UserStore<ApplicationUser>。
UserStore<TUser>(Microsoft.AspNet.Identity.EntityFramework,Microsoft.AspNet.Identity.EntityFramework.dll)
这个类实现IUserStore<TUser>接口以及一系列相关接口(比如:IUserLoginStore<TUser>等)。这个类实际上为UserManager提供了对用户真实数据的访问能力,在这里,是把用户数据通过EntityFramework来存储和获取的(而数据实际是保存中SQL Server的各类版本中还是保存在MySQL中,就又取决于EntityFramework的数据库驱动适配层了,和这个分层架构实际上无关了)。而由于UserStore<TUser>是依赖于EntityFramework来存取数据的,所以他的构造函数也接受DbContext作为参数:
public UserStore(DbContext context);
虽然DbContext是一个通用的类,不过从AccountController的构造函数中,我们还是可以看到实际上传入的是一个继承于IdentityDbContext<TUser>的DbContext。
IdentityDbContext<TUser>(Microsoft.AspNet.Identity.EntityFramework,Microsoft.AspNet.Identity.EntityFramework.dll)
这是一个包含了Code-First模型定义的DbContext了,其中当然定义了Users这个IDbSet<TUser>,所以对用户数据的操作最终都是由这个DbContext完成的。
类似架构的讲解
这里的这篇文章(http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen)其实就讲解了这种类似的分层架构。
其中,文章中提到的IRepository(特定于某个领域类的ICategoryRepository)就是IUserStore,而CategoryRepository就类似于UserStore<TUser>,而CatalogService和UserManager比较接近。
通过依赖注入充分利用这种架构的灵活性
从上面的这些类的构造函数中,我们还可以看到以各种重要特点,就是好几个类都具有参数构造函数,这样的设计不得不说是为了依赖注入而准备了。所以,我也简单讲解一下如何用Unity来进行简单的依赖注入(其他依赖注入框架用法类似)。
首先,通过NuGet来添加Unity和Unity.Mvc这两个包。
添加以后,在App_Start文件夹里面会出现两个文件:UnityConfig.cs和UnityMvcActivator.cs,在UnityConfig.cs文件中的RegisterTypes函数中,添加如下两行代码:
container.RegisterType<IUserStore<ApplicationUser>, UserStore<ApplicationUser>>();
container.RegisterType<DbContext, ApplicationDbContext>();
就可以非常简单地利用Unity来把相关实现类注入进去。所以在这里,你可以把自己实现的UserStore注入进去,假设你的UserStore用到的是类似MongoDB这样的NoSQL的话,那么你同样也可以把MongoDB的session注入进去。
通过定义接口,基于接口实现,并在相关类上暴露具有参数的构造函数,可以实现各个分层实现之间的松耦合,并通过依赖注入来极大的增加代码的灵活性。
总结
在我们的实际项目开发中,如果为了获得灵活性完全可以照搬这种模式;当然,如果只是想快速实现一个原型或者就是一个小项目的话,那么在Controller里面直接调用DbContext也没有什么大不了的。
update-2013-11-04 关于ASP.NET Identity的更多信息,可以参考官方文档:http://www.asp.net/identity/overview/getting-started