一、前言
DependencyResolver是MVC中一个重要的组件,从名字可以看出,它负责依赖对象的解析,可以说它是MVC框架内部使用的一个IOC容器。MVC内部很多对象的创建都是通过它完成的,或许我们平时没有直接用到它,但是如果你在使用unity、autofac,或者在看一些开源项目时,总会看到它的身影。接下来就让我们看一下这个组件是如何工作的。
二、通过Controller的激活理解DependencyResolver的工作过程
这里先插一个题外话,经常会有面试问:asp.net 几个核心对象是什么?一般人都会回答:Server、Request、Response、Sesshtml" target="_blank">ion、Cookie这些。但我的回答会是HttpApplication、HttpHandler和HttpModule,这才是管道模型中的核心类型,整个asp.net的处理流程和可扩展性也都是建立在这几个对象上的。
回到主题,asp.net请求都是交给HttpHandler处理的,对于MVC来说,是交给一个MvcHandler,它负责激活Controller,如果你不知道为什么,请看这里。在这里我们直接定位到MvcHandler的PR方法:
protected internal virtual IAsyncResult BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, object state) { IController controller; IControllerFactory factory; ProcessRequestInit(httpContext, out controller, out factory); //其它操作 //调用 controller.Execute方法 } private void ProcessRequestInit(HttpContextBase httpContext, out IController controller, out IControllerFactory factory) { HttpContext currentContext = HttpContext.Current; //从路由获取controller名称 string controllerName = RequestContext.RouteData.GetRequiredString("controller"); //通过ControllerBuilder获取ControllerFactory,默认就是DefaultControllerFactory factory = ControllerBuilder.GetControllerFactory(); //通过ControllerFactory获取Controller对象 controller = factory.CreateController(RequestContext, controllerName); }
ControllerFactory故名思议就是用于创建Controller的,我们也可以自己实现IControllerFactory,参与Controller的激活过程,具体是在全局调用ControllerBuilder.Current.SetControllerFactory方法。我们这里主要关注的是Controller的激活过程,实际上它们的创建过程是相似的。默认使用的ControllerFactory是DefaultControllerFactory。DefaultControllerFactory的CreateController方法如下:
public virtual IController CreateController(RequestContext requestContext, string controllerName) { //获取Controller类型 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); }
可以看到,它通过一个ControllerActivator来创建IController对象,默认使用的是DefaultControllerActivator。与ControllerFactory类似,我们可以实现IControllerActivator,参与Controller的激活过程,具体是将ControllerActivator作为DefaultConrtollerFactory构造函数参数,然后再在全局调用ControllerBuilder.Current.SetControllerFactory方法。可以看到MVC的Controller激活过程是很灵活的,它提供多种方式让我们自定义激活过程。DefaultControllerActivator定义如下:
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是一个用于获取IDepencyResolver对象的委托,实际获得的是DependencyResolver.Current。我们也可以自己实现IDependencyResolver,参与Controller的激活过程,具体是在全局调用DependencyResolver的静态方法SetResolver方法。需要注意的是这里的DependencyResolver类型(这里是类型,而其它地方提到的DependencyResolver都是组件的意思)并没有实现IDependencyResolver接口,我觉得将它命名为DependencyResolverContainer会更合适一些。IDepdencyResolver接口的定义如下:
public interface IDependencyResolver { object GetService(Type serviceType); IEnumerable<object> GetServices(Type serviceType); }
默认DependencyResolver.Current使用的是DefaultDependencyResolver类型,这里又和ControllerFactory和ControllerActivator的设计一样了,如果我们自定义,那么就使用,否则就使用默认的。DefaultDependencyResolver定义如下:
private class DefaultDependencyResolver : IDependencyResolver { public object GetService(Type serviceType) { if (serviceType.IsInterface || serviceType.IsAbstract) { return null; } try { //如果Controller Type创建Controller实例对象 return Activator.CreateInstance(serviceType); } catch { return null; } } public IEnumerable<object> GetServices(Type serviceType) { return Enumerable.Empty<object>(); } }
可以看到,MVC会将Controller对象的创建通过DependencyResolver完成。将对象的创建通过DependencyResolver完成的好处是可以降低对象间的耦合度;另外,通过实现IDependencyResolver接口,我们可以完全控制对象的创建过程,例如将对象的依赖关系转移到配置文件中等等。
通过上面我们还知道了有三种默认类型:DefaultControllerFactory、DefaultControllerActivator和DefaultDependencyResolver,分别对应三个接口:IControllerFactory、IControllerActivator、IDependencyResolver。它们的设计是类似的,都是提供给外部一个接口,如果外部自己实现了这个过程,那么就使用,否则用默认的。实际上这也是我们参与Controller激活过程的三种做法。
三、实现IDependencyResolver接口
接下来通过一个例子证明上面的过程。我们要实现的需求是通过实现IDependencyResolver接口,实现Controller构造函数注入服务。如:
public class HomeController : Controller { private IUserService _service; public HomeController(IUserService service) { _service = service; } public ActionResult Index() { return Content(_service.GetUserName()); } }
HomeController只依赖于IUserService接口,不依赖于具体对象。
接下来我们实现IDependencyResolver接口,依赖注入的实现方式有很多种,这里我们使用Unity。如下:
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) 原因是我们前面说过的,MVC内部很多对象都是通过DependencyResolver组件创建的,如上面的IConrtollerFactoy,所以这里我们只负责对已注册的类型或类(非抽象类)进行解析。
Ioc类在这里很简单,如下:
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方法中,注册Service和设置IocDependencyResolver:
Ioc.RegisterType<IUserService, UserService>();
DependencyResolver.SetResolver(new IocDependencyResolver());
运行就可以看到HomeController构造函数的IUserService就是UserService类型了。
四、总结
实际上,上面的例子我们也可以用实现IControllerFactory或者IControllerActivator达到同样的目的,但使用IDependencyResolver会更简单一点,而且大部分的IOC框架都已经提供了这样的功能。例如上面UnityDependencyResolver根本不用自己定义,Unity for MVC 已经有这么一个类型了,直接使用即可。如果使用Autofac的话可以是:DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
以上就是本文的全部内容,希望对大家的学习有所帮助。
> 在ES6中直接初始化类上的属性是不可能的,目前只能用这种方式声明方法。同样的规则也存在于ES7中。 https://stackoverflow.com/a/38269333/4942980 render方法中的一个函数将在每个呈现中创建,这对性能有一点影响。如果你把它们放在渲染图中也很乱 ...更喜欢只将专门处理呈现组件和/或JSX的函数放在render中(即,在prop上进行映射,根据pro
11.5. 剖析 基准测试(Benchmark)对于衡量特定操作的性能是有帮助的,但是当我们试图让程序跑的更快的时候,我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思,但是从原文我们可以看到不同的含义: 毫无疑问,对效率的
以下各节的脚本展示了如何通过监控函数调用来剖析(profile)内核活动。 统计函数调用次数 本节展示如何统计30秒内某个内核函数调用次数。通过使用通配符,你可以用这个脚本同时统计多个内核函数。 functioncallcount.stp #! /usr/bin/env stap # The following line command will probe all the functions #
到目前为止,我们只是载入文档,然后再输出它。 现在看看更让我们感兴趣的剖析树: Beautiful Soup剖析一个文档后生成的数据结构。 剖析对象 (BeautifulSoup或 BeautifulStoneSoup的实例)是深层嵌套(deeply-nested), 精心构思的(well-connected)的数据结构,可以与XML和HTML结构相互协调。 剖析对象包括2个其他类型的对象,Tag
如果你从源码编译时启用了 oprofile ,那就可以剖析 Ceph 的 CPU 使用情况,详情见安装 Oprofile 。 初始化 oprofile 你首次使用 oprofile 时要初始化,找到对应于当前运行内核的 vmlinux 映像: ls /boot sudo opcontrol --init sudo opcontrol --setup --vmlinux={path-to-image
问题内容: 获取有关go程序的概要分析信息的最佳方法是什么?我见过对pprof的引用,但是与Go的其他领域相比,文档似乎很少。 问题答案: 看一下 命令。请注意,尽管名称如此,它适用于所有体系结构。 出于歧义的原因,它虽然安装为6prof,但也可以充当8prof和5prof。