从Microsoft.AspNet.Identity看微软推荐的一种MVC的分层架构

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提供了两个构造方法:

  1. 一个默认的:
     public AccountController()
                : this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))
            {
            }
  2. 一个可以传入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

分享到: 更多
posted @ 2013-10-28 21:47  朱永光  阅读(19116)  评论(9编辑  收藏  举报