一、前言
DependencyResolver是MVC中一個(gè)重要的組件,從名字可以看出,它負(fù)責(zé)依賴(lài)對(duì)象的解析,可以說(shuō)它是MVC框架內(nèi)部使用的一個(gè)IOC容器。MVC內(nèi)部很多對(duì)象的創(chuàng)建都是通過(guò)它完成的,或許我們平時(shí)沒(méi)有直接用到它,但是如果你在使用unity、autofac,或者在看一些開(kāi)源項(xiàng)目時(shí),總會(huì)看到它的身影。接下來(lái)就讓我們看一下這個(gè)組件是如何工作的。
二、通過(guò)Controller的激活理解DependencyResolver的工作過(guò)程
這里先插一個(gè)題外話(huà),經(jīng)常會(huì)有面試問(wèn):asp.net 幾個(gè)核心對(duì)象是什么?一般人都會(huì)回答:Server、Request、Response、Session、Cookie這些。但我的回答會(huì)是HttpApplication、HttpHandler和HttpModule,這才是管道模型中的核心類(lèi)型,整個(gè)asp.net的處理流程和可擴(kuò)展性也都是建立在這幾個(gè)對(duì)象上的。
回到主題,asp.net請(qǐng)求都是交給HttpHandler處理的,對(duì)于MVC來(lái)說(shuō),是交給一個(gè)MvcHandler,它負(fù)責(zé)激活Controller,如果你不知道為什么,請(qǐng)看這里。在這里我們直接定位到MvcHandler的PR方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
protected internal virtual IAsyncResult BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, object state) { IController controller; IControllerFactory factory; ProcessRequestInit(httpContext, out controller, out factory); //其它操作 //調(diào)用 controller.Execute方法 } private void ProcessRequestInit(HttpContextBase httpContext, out IController controller, out IControllerFactory factory) { HttpContext currentContext = HttpContext.Current; //從路由獲取controller名稱(chēng) string controllerName = RequestContext.RouteData.GetRequiredString( "controller" ); //通過(guò)ControllerBuilder獲取ControllerFactory,默認(rèn)就是DefaultControllerFactory factory = ControllerBuilder.GetControllerFactory(); //通過(guò)ControllerFactory獲取Controller對(duì)象 controller = factory.CreateController(RequestContext, controllerName); } |
ControllerFactory故名思議就是用于創(chuàng)建Controller的,我們也可以自己實(shí)現(xiàn)IControllerFactory,參與Controller的激活過(guò)程,具體是在全局調(diào)用ControllerBuilder.Current.SetControllerFactory方法。我們這里主要關(guān)注的是Controller的激活過(guò)程,實(shí)際上它們的創(chuàng)建過(guò)程是相似的。默認(rèn)使用的ControllerFactory是DefaultControllerFactory。DefaultControllerFactory的CreateController方法如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public virtual IController CreateController(RequestContext requestContext, string controllerName) { //獲取Controller類(lèi)型 Type controllerType = GetControllerType(requestContext, controllerName); IController controller = GetControllerInstance(requestContext, controllerType); return controller; } protected internal virtual IController GetControllerInstance(RequestContext requestContext, Type controllerType) { return ControllerActivator.Create(requestContext, controllerType); } |
可以看到,它通過(guò)一個(gè)ControllerActivator來(lái)創(chuàng)建IController對(duì)象,默認(rèn)使用的是DefaultControllerActivator。與ControllerFactory類(lèi)似,我們可以實(shí)現(xiàn)IControllerActivator,參與Controller的激活過(guò)程,具體是將ControllerActivator作為DefaultConrtollerFactory構(gòu)造函數(shù)參數(shù),然后再在全局調(diào)用ControllerBuilder.Current.SetControllerFactory方法??梢钥吹組VC的Controller激活過(guò)程是很靈活的,它提供多種方式讓我們自定義激活過(guò)程。DefaultControllerActivator定義如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
private class DefaultControllerActivator : IControllerActivator { private Func<IDependencyResolver> _resolverThunk; public DefaultControllerActivator() : this ( null ) { } public DefaultControllerActivator(IDependencyResolver resolver) { if (resolver == null ) { _resolverThunk = () => DependencyResolver.Current; } else { _resolverThunk = () => resolver; } } public IController Create(RequestContext requestContext, Type controllerType) { try { return (IController)(_resolverThunk().GetService(controllerType) ?? Activator.CreateInstance(controllerType)); } catch (Exception ex) { } } } |
這里的_resolverThunk是一個(gè)用于獲取IDepencyResolver對(duì)象的委托,實(shí)際獲得的是DependencyResolver.Current。我們也可以自己實(shí)現(xiàn)IDependencyResolver,參與Controller的激活過(guò)程,具體是在全局調(diào)用DependencyResolver的靜態(tài)方法SetResolver方法。需要注意的是這里的DependencyResolver類(lèi)型(這里是類(lèi)型,而其它地方提到的DependencyResolver都是組件的意思)并沒(méi)有實(shí)現(xiàn)IDependencyResolver接口,我覺(jué)得將它命名為DependencyResolverContainer會(huì)更合適一些。IDepdencyResolver接口的定義如下:
1
2
3
4
5
|
public interface IDependencyResolver { object GetService(Type serviceType); IEnumerable< object > GetServices(Type serviceType); } |
默認(rèn)DependencyResolver.Current使用的是DefaultDependencyResolver類(lèi)型,這里又和ControllerFactory和ControllerActivator的設(shè)計(jì)一樣了,如果我們自定義,那么就使用,否則就使用默認(rèn)的。DefaultDependencyResolver定義如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
private class DefaultDependencyResolver : IDependencyResolver { public object GetService(Type serviceType) { if (serviceType.IsInterface || serviceType.IsAbstract) { return null ; } try { //如果Controller Type創(chuàng)建Controller實(shí)例對(duì)象 return Activator.CreateInstance(serviceType); } catch { return null ; } } public IEnumerable< object > GetServices(Type serviceType) { return Enumerable.Empty< object >(); } } |
可以看到,MVC會(huì)將Controller對(duì)象的創(chuàng)建通過(guò)DependencyResolver完成。將對(duì)象的創(chuàng)建通過(guò)DependencyResolver完成的好處是可以降低對(duì)象間的耦合度;另外,通過(guò)實(shí)現(xiàn)IDependencyResolver接口,我們可以完全控制對(duì)象的創(chuàng)建過(guò)程,例如將對(duì)象的依賴(lài)關(guān)系轉(zhuǎn)移到配置文件中等等。
通過(guò)上面我們還知道了有三種默認(rèn)類(lèi)型:DefaultControllerFactory、DefaultControllerActivator和DefaultDependencyResolver,分別對(duì)應(yīng)三個(gè)接口:IControllerFactory、IControllerActivator、IDependencyResolver。它們的設(shè)計(jì)是類(lèi)似的,都是提供給外部一個(gè)接口,如果外部自己實(shí)現(xiàn)了這個(gè)過(guò)程,那么就使用,否則用默認(rèn)的。實(shí)際上這也是我們參與Controller激活過(guò)程的三種做法。
三、實(shí)現(xiàn)IDependencyResolver接口
接下來(lái)通過(guò)一個(gè)例子證明上面的過(guò)程。我們要實(shí)現(xiàn)的需求是通過(guò)實(shí)現(xiàn)IDependencyResolver接口,實(shí)現(xiàn)Controller構(gòu)造函數(shù)注入服務(wù)。如:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class HomeController : Controller { private IUserService _service; public HomeController(IUserService service) { _service = service; } public ActionResult Index() { return Content(_service.GetUserName()); } } |
HomeController只依賴(lài)于IUserService接口,不依賴(lài)于具體對(duì)象。
接下來(lái)我們實(shí)現(xiàn)IDependencyResolver接口,依賴(lài)注入的實(shí)現(xiàn)方式有很多種,這里我們使用Unity。如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public class UnityDependencyResolver : IDependencyResolver { public object GetService(Type serviceType) { if (serviceType == null ) { throw new ArgumentNullException( "serviceType" ); } return (serviceType.IsClass && !serviceType.IsAbstract) || Ioc.IsRegistered(serviceType) ? Ioc.GetService(serviceType) : null ; } public IEnumerable< object > GetServices(Type serviceType) { if (serviceType == null ) { throw new ArgumentNullException( "serviceType" ); } return (serviceType.IsClass && !serviceType.IsAbstract) || Ioc.IsRegistered(serviceType) ? Ioc.GetServices(serviceType) : null ; } } |
這里需要判斷 (serviceType.IsClass && !serviceType.IsAbstract) || Ioc.IsRegistered(serviceType) 原因是我們前面說(shuō)過(guò)的,MVC內(nèi)部很多對(duì)象都是通過(guò)DependencyResolver組件創(chuàng)建的,如上面的IConrtollerFactoy,所以這里我們只負(fù)責(zé)對(duì)已注冊(cè)的類(lèi)型或類(lèi)(非抽象類(lèi))進(jìn)行解析。
Ioc類(lèi)在這里很簡(jiǎn)單,如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public class Ioc { private static IUnityContainer _container = new UnityContainer(); public static void RegisterType<TFrom,TTo>() where TTo : TFrom { _container.RegisterType<TFrom, TTo>(); } public static object GetService(Type type) { return _container.Resolve(type); } public static IEnumerable< object > GetServices(Type type) { return _container.ResolveAll(type); } public static bool IsRegistered(Type type) { return _container.IsRegistered(type); } } |
接著,在Application_Start方法中,注冊(cè)Service和設(shè)置IocDependencyResolver:
Ioc.RegisterType<IUserService, UserService>();
DependencyResolver.SetResolver(new IocDependencyResolver());
運(yùn)行就可以看到HomeController構(gòu)造函數(shù)的IUserService就是UserService類(lèi)型了。
四、總結(jié)
實(shí)際上,上面的例子我們也可以用實(shí)現(xiàn)IControllerFactory或者IControllerActivator達(dá)到同樣的目的,但使用IDependencyResolver會(huì)更簡(jiǎn)單一點(diǎn),而且大部分的IOC框架都已經(jīng)提供了這樣的功能。例如上面UnityDependencyResolver根本不用自己定義,Unity for MVC 已經(jīng)有這么一個(gè)類(lèi)型了,直接使用即可。如果使用Autofac的話(huà)可以是:DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助。