自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的模样。

我们先行来拘禁一个类图:

图片 1

自从达图被,我们得看看如下类以及他们的干:

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

网站地图xml地图