继上一篇文章之后,本文将介绍 Controller 和 Action 的一些较高级特性,包括 Controller Factory、Action Invoker 和异步 Controller 等内容。
本文目录
开篇:示例准备
文章开始之前,我们先来了解一下一个请求的发出到Action方法处理后返回结果的流程,请试着理解下图:
本文的重点是 controller factory 和 action invoker。顾名思义,controller factory 的作用是创建为请求提供服务的Controller实例;action invoker 的作用是寻找并调用Action方法。MVC框架为这两者都提供了默认的实现,我们也可以对其进行自定义。
首先我们为本文要演示的示例做一些准备,把暂时想到的要用的 View、Controller 和 Action 都创建好。新建一个空的MVC应用程序,在Models文件夹中添加一个名为 Result 的Model,代码如下:
namespace MvcApplication2.Models { public class Result { public string ControllerName { get; set; } public string ActionName { get; set; } } }
在 /Views/Shared 文件夹下添加一个名为 Result.cshtml 的视图(不使用Layout),添加代码如下:
... <body> <div>Controller: @Model.ControllerName</div> <div>Action: @Model.ActionName</div> </body>
本文的所有Action方法将都使用这同一个View,目的是显示被执行的Controller名称和Action名称。
然后我们创建一个名为Product的Controller,代码如下:
public class ProductController : Controller { public ViewResult Index() { return View("Result", new Result { ControllerName = "Product", ActionName = "Index" }); } public ViewResult List() { return View("Result", new Result { ControllerName = "Product", ActionName = "List" }); } }
继续添加一个名为Customer的Controller,代码如下:
public class CustomerController : Controller { public ViewResult Index() { return View("Result", new Result { ControllerName = "Customer", ActionName = "Index" }); } public ViewResult List() { return View("Result", new Result { ControllerName = "Customer", ActionName = "List" }); } }
准备工作做好了,开始进入正题吧。
自定义 Controller Factory
Controller Factory,顾名思义,它就是创建 controller 实例的地方。想更好的理解Controller Factory是如何工作的,最好的方法就是自己去实现一个自定义的。当然,在实际的项目中我们很少会去自己实现,一般使用内置的就足够。自定义一个Controller Factory需要实现 IControllerFactory 接口,这个接口的定义如下:
using System.Web.Routing; using System.Web.SessionState; namespace System.Web.Mvc { public interface IControllerFactory { IController CreateController(RequestContext requestContext, string controllerName); SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName); void ReleaseController(IController controller); } }
我们创建一个名为 Infrastructure 文件夹,在这个文件夹中创建一个名为 CustomControllerFactory 的类文件,在这个类中我们将简单的实现 IControllerFactory 接口的每个方法,代码如下:
using System; using System.Web.Mvc; using System.Web.Routing; using System.Web.SessionState; using MvcApplication2.Controllers; namespace MvcApplication2.Infrastructure { public class CustomControllerFactory : IControllerFactory { public IController CreateController(RequestContext requestContext, string controllerName) { Type targetType = null; switch (controllerName) { case "Product": targetType = typeof(ProductController); break; case "Customer": targetType = typeof(CustomerController); break; default: requestContext.RouteData.Values["controller"] = "Product"; targetType = typeof(ProductController); break; } return targetType == null ? null : (IController)DependencyResolver.Current.GetService(targetType); } public SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName) { return SessionStateBehavior.Default; } public void ReleaseController(IController controller) { IDisposable disposable = controller as IDisposable; if (disposable != null) { disposable.Dispose(); } } } }
先来分析一下这个类。
这里最重要的方法是 CreateController,当MVC框架需要一个 Controller 来处理请求时调用该方法。它有两个参数,一个是 RequestContext 对象,通过它我们可以得到请求相关的信息;第二个参数是一个string类型的controller名称,它的值来自于URL。这里我们只创建了两个Controller,所以我们在 CreateController 方法中进行了硬编码(写死了controller的名称),CreateController 方法的目的是创建Controller实例。
在自定义的Cotroller Factory中,我们可以任意改变系统默认的行为,比如switch语句中的default节点:
requestContext.RouteData.Values["controller"] = "Product";
它将路由的controller值改为Product,使得执行的cotroller并不是用户所请求的controller。
在本系列的 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 文章中也讲了一个用 Ninject 创建Controller Factory的例子,使用的是 ninjectKernel.Get(controllerType) 方法来创建Controller实例。这里我们使用 MVC 框架提供的 DependencyResolver 类来创建:
return targetType == null ? null : (IController)DependencyResolver.Current.GetService(targetType);
静态的 DependencyResolver.Current 属性返回一个 IDependencyResolver 接口的实现,这个实现中定义了 GetService 方法,它根据 System.Type 对象(targetType)参数自动为我们创建 targetType 实例,和使用Ninject类似。
最后来看看实现 IControllerFactory 接口的另外两个方法。
GetControllerSessionBehavior 方法,告诉MVC框架是否保留Session数据,这点放在文章后面讲。
ReleaseController 方法,当controller对象不再需要时被调用,这里我们判断controller对象是否实现了IDisposable接口,实现了则调用 Dispose 方法来释放资源。
CustomControllerFactory 类分析完了。和 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 讲的示例一样,要使用自定义的Controller Factory还需要在 Global.asax.cs 文件的 Application_Start 方法中对自定义的 CustomControllerFactory 类进注册,如下:
protected void Application_Start() { ... ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory()); }
运行程序,应用程序根据路由设置的默认值显示如下:
你可以定位到任意 /xxx/xxx 格式的URL来验证我们自定的 Controller Factory 的工作。
使用内置的 Controller Factory
为了帮助理解Controller Factory是如何工作,我们通过实现IControllerFactory接口自定义了一个Controller Factory。在实际的项目中,我们一般不会这么做,大多数情况我们使用内置的Controller Factory,叫 DefaultControllerFactory。当它从路由系统接收到一个请求后,从路由实例中解析出 controller 的名称,然后根据名称找到 controller 类,这个类必须满足下面几个标准:
- 必须是public。
- 必须是具体的类(非抽象类)。
- 没有泛型参数。
- 类的名称必须以Controller结尾。
- 类必须(间接或直接)实现IController接口。
DefaultControllerFactory类维护了一个满足以上标准的类的列表,这样当每次接收到一个请求时不需要再去搜索一遍。当它找到了合适的 controller 类,则使用Controller Activator(一会介绍)来创建Controller 类的实例。它内部是通过 DependencyResolver 类进行依赖解析创建 controller 实例的,和使用Ninject是类似的原理。
你可以通过继承 DefaultControllerFactory 类重写其中默认的方法来自定义创建 controller 的过程,下面是三个可以被重写的方法:
- GetControllerType,返回Type类型,为请求匹配对应的 controller 类,用上面定义的标准来筛选 controller 类也是在这里执行的。
- GetControllerInstance,返回是IController类型,作用是根据指定 controller 的类型创建类型的实例。
- CreateController 方法,返回是 IController 类型,它是 IControllerFactory 接口的 CreateController 方法的实现。默认情况下,它调用 GetControllerType 方法来决定哪个类需要被实例化,然后把controller 类型传递给GetControllerInstance。
重写 GetControllerInstance 方法,可以实现对创建 controller 实例的过程进行控制,最常见的是进行依赖注入。
在本系列的 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 文章中的示例就是一个对 GetControllerInstance 方法进行重写的完整示例,在这就不重复演示了。
现在我们知道 DefaultControllerFactory 通过 GetControllerType 方法拿到 controller 的类型后,它把类型传递给 GetControllerInstance 方法以获取 controller 的实例。那么,GetControllerInstance 又是如何来获取实例的呢?这就需要讲到另外一个 controller 中的角色了,它就是下面讲的:Controller Activator。
Controller 的激活
当 DefaultControllerFactory 类接收到一个 controller 实例的请求时,在 DefaultControllerFactory 类内部通过 GetControllerType 方法来获得 controller 的类型,然后把这个类型传递给 GetControllerInstance 方法以获得 controller 的实例。
所以在 GetControllerInstance 方法中就需要有某个东西来创建 controller 实例,这个创建的过程就是 controller 被激活的过程。
默认情况下 MVC 使用 DefaultControllerActivator 类来做 controller 的激活工作,它实现了 IControllerActivator 接口,该接口定义如下:
public interface IControllerActivator { IController Create(RequestContext requestContext, Type controllerType); }
该接口仅含有一个 Create 方法,RequestContext 对象参数用来获取请求相关的信息,Type 类型参数指定了要被实例化的类型。DefaultControllerActivator 类中整个 controller 的激活过程就在它的 Create 方法里面。下面我们通过实现这个接口来自定义一个简单的 Controller Activator:
public class CustomControllerActivator : IControllerActivator { public IController Create(RequestContext requestContext, Type controllerType) { if (controllerType == typeof(ProductController)) { controllerType = typeof(CustomerController); } return (IController)DependencyResolver.Current.GetService(controllerType); } }
这个 CustomControllerActivator 非常简单,如果请求的是 ProductController 则我们给它创建 CustomerController 的实例。为了使用这个自定的 Activator,需要在 Global.asax 文件中的 Application_Start 方法中注册 Controller Factory 时给 Factory 的构造函数传递我们的这个 Activator 的实例,如下:
protected void Application_Start() { ... ControllerBuilder.Current.SetControllerFactory(new DefaultControllerFactory(new CustomControllerActivator())); }
运行程序,把URL定位到 /Product ,本来路由将指定到 Product controller, 然后 DefaultControllerFactory 类将请求 Activator 创建一个 ProductController 实例。但我们注册了自义的 Controller Activator,在这个自定义的 Activator 创建 Controller 实例的的时候,我们做了一个“手脚”,改变了这种默认行为。当请求创建 ProductController 实例时,我们给它创建了CustomerController 的实例。结果如下:
其实更多的时候,我们自定义 controller 的激活机制是为了引入IoC,和 [ASP.NET MVC 小牛之路]05 - 使用 Ninject 讲的通过继承 DefaultControllerFactory 引入 IoC 是一个道理。
自定义 Action Invoker
当 Controller Factory 创建好了一个类的实例后,MVC框架则需要一种方式来调用这个实例的 action 方法。如果创建的 controller 是继承 Controller 抽象类的,那么则是由 Action Invoker 来完成调用 action 方法的任务,MVC 默认使用的是 ControllerActionInvoker 类。如果是直接继承 IController 接口的 controller,那么就需要手动来调用 action 方法,见上一篇 [ASP.NET MVC 小牛之路]09 - Controller 和 Action (1) 。下面我们通过自定义一个 Action Invoker 来了解一下 Action Invoker 的运行机制。
创建一个自定义的 Action Invoker 需要实现 IActionInvoker 接口,该接口的定义如下:
public interface IActionInvoker { bool InvokeAction(ControllerContext controllerContext, string actionName); }
这个接口只有一个 InvokeAction 方法。ControllerContext 对象参数包含了调用该方法的controller的信息,string类型的参数是要调用的Action方法的名称,这个名称来源于路由系统。返回值为bool类型,当actoin方法被找到并被调用时返回true,否则返回false。
下面是实现了IActionInvoker接口的 CustomActionInvoker 类:
using System.Web.Mvc; namespace MvcApplication2.Infrastructure { public class CustomActionInvoker : IActionInvoker { public bool InvokeAction(ControllerContext controllerContext, string actionName) { if (actionName == "Index") { controllerContext.HttpContext.Response.Write("This is output from the Index action"); return true; } else { return false; } } } }
这个 CustomActionInvoker 不需要关心实际被调用的Action方法。如果请求的是Index Action,这个 Invoker 通过 Response 直接输出一个消息,如果不是请Index Action,则会引发一个404-未找到错误。
决定Controller使用哪个Action Invoker是由 Controller 中的 Controller.ActionInvoker 属性来决定的,由它来告诉MVC当前的 controller 将使用哪个 Action Invoker 来调用 Action 方法。如下我们创建一个ActionInvokerController,并在它的构造函数中指定了 Action Invoker 为我们自定义的 Action Invoker:
namespace MvcApplication2.Controllers { public class ActionInvokerController : Controller { public ActionInvokerController() { this.ActionInvoker = new CustomActionInvoker(); } } }
这个 controller 中没有 Action 方法,它依靠 CustomActionInvoker 来处理请求。运行程序,将URL定位到 /ActionInvoker/Index 可见如下结果:
如果将URL定位到 ActionInvoker 下的其他Action,则会返回一个404的错误页面。
我们不推荐去实现自己的Action Invoker。首先内置的Action Invoker提供了一些非常有用的特性;其次是缺乏可扩展性和对View的支持等。这里只是为了演示和理解MVC框架处理请求过程的细节。
使用内置的 Action Invoker
通过自定义 Action Invoker,我们知道了MVC调用 Action 方法的机制。我们创建一个继承自 Controller 抽象类的 controller,如果不指定Controller.ActionInvoker,那么MVC会使用内置默认的Action Invoker,它是 ControllerActionInvoker 类。它的工作是把请求匹配到对应的 Action 方法并调用之,简单说就是寻找和调用 Action 方法。
为了让内置的 Action Invoker 能匹配到 Action 方法,Action方法必须满足下面的标准:
- 必须是公共的(public)。
- 不能是静态的(static)。
- 不能是System.Web.Mvc.Controller中存在的方法,或其他基类中的方法。如方法不能是 ToString 和 GetHashCode 等。
- 不能是一个特殊的名称。所谓特殊的名称是方法名称不能和构造函数、属性或者事件等的名称相同。
注意,Action方法也不能带有泛型,如MyMethod<T>(),虽然 Action Invoker 能匹配到,但会抛出异常。
内置的 Action Invoker 给我们提供了很多实用的特性,给开发带来很大便利,下面两节内容可以说明这一点。
给 Action 方法定义别名
默认情况下,内置的Action Invoker (ControllerActionInvoker)寻找的是和请求的 action 名称相同的 action 方法。比如路由系统提供的 action 值是 Index,那么 ControllerActionInvoker 将寻找一个名为 Index 的方法,如果找到了,它就用这个方法来处理请求。ControllerActionInvoker 允许我们对此行为进行调整,即可以通过使用 ActionName 特性对 action 使用别名,如下对 CustomerController 的 List action 方法使用 ActionName 特性:
public class CustomerController : Controller { ... [ActionName("Enumerate")] public ViewResult List() { return View("Result", new Result { ControllerName = "Customer", ActionName = "List" }); } }
当请求 Enumerate Action 时,将会使用 List 方法来处理请求。下面是请求 /Customer/Enumerate 的结果:
这时候对 /Customer/List 的请求则会无效,报“找不到资源”的错误,如下:
使用 Action 方法别名有两个好处:一是可以使用非法的C#方法名来作为请求的 action 名,如 [ActionName("User-Registration")]。二是,如果你有两个功能不同的方法,有相同的参数相同的名称,但针对不同的HTTP请求(一个使用 [HttpGet],另一个使用 [HttpPost]),你可以给这两个方法不同的方法名,然后使用 [ActionName] 来指定相同的 action 请求名称。
Action 方法选择器
我们经常会在 controller 中对多个 action 方法使用同一个方法名。在这种情况下,我们就需要告诉 MVC 怎样在相同的方法名中选择正确的 action 方法来处理请求。这个机制称为 Action 方法选择,它在基于识别方法名称的基础上,允许通过请求的类型来选择 action 方法。MVC 框架可使用C#特性来做到这一点,所以这种作用的特性可以称为 Action 方法选择器。
内置 Action 方法选择器
MVC提供了几种内置的特性来支持 Action 方法选择,它包括HttpGet、HttpPost、HttpPut 和 NonAction 等。这些选择器从名字上很容易理解什么意思,这里就不解释了。下面举个 NonAction 的例子。在 CustomerController 中添加一个 MyAction 方法,然后应用 [NonAction] 特性,如下:
public class CustomerController : Controller { ... [NonAction] public ActionResult MyAction() { return View(); } }
使用 [NonAction] 后,方法将不会被识别为 action 方法,如下是请求 /Customer/MyAction 的结果:
当然我们也可以通过把方法声明为 private 来告诉MVC它不是一个 action 方法。
自定义 Action 方法选择器
除了使用内置的Action方法选择器外,我们也可以自定义。所有的 action 选择器都继承自 ActionMethodSelectorAttribute 类,这个类的定义如下:
using System.Reflection; namespace System.Web.Mvc { [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)] public abstract class ActionMethodSelectorAttribute : Attribute { public abstract bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo); } }
它是一个抽象类,只有一个抽象方法:IsValidForRequest。通过重写这个方法,可以判断某个请求是否允许调用 Action 方法。
我们来考虑这样一种情况:同一个URL请求,在本地和远程请求的是不同的 action (如对于本地则绕过权限验证可能需要这么做)。那么自定义一个本地的 Action 选择器会是一个不错的选择。下面我们来实现这样一个功能的 Action 选择器:
using System.Reflection; using System.Web.Mvc; namespace MvcApplication2.Infrastructure { public class LocalAttribute : ActionMethodSelectorAttribute { public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo) { return controllerContext.HttpContext.Request.IsLocal; } } }
修改 CustomerController,添加一个LocalIndex 方法,并对它应用 “Index”别名,代码如下:
public class CustomerController : Controller { public ViewResult Index() { return View("Result", new Result { ControllerName = "Customer", ActionName = "Index" }); } [ActionName("Index")] public ViewResult LocalIndex() { return View("Result", new Result { ControllerName = "Customer", ActionName = "LocalIndex" }); } ... }
这时如果请求 /Customer/Index,这两个 action 方法都会被匹配到而引发歧义问题,程序将会报错:
这时候我们再对 LocalIndex 应用我们自定义的 Local 选择器:
... [Local] [ActionName("Index")] public ViewResult LocalIndex() { return View("Result", new Result { ControllerName = "Customer", ActionName = "Index" }); } ...
程序在本地运行的时候则会匹配到 LocalIndex action方法,结果如下:
通过这个例子我们也发现,定义了选择器特性的Action方法被匹配的优先级要高于没有定义选择器特性的Action方法。
异步 Controller
对于 ASP.NET 的工作平台 IIS,它维护了一个.NET线程池用来处理客户端请求。这个线程池称为工作线程池(worker thread pool),其中的线程称为工作线程(worker threads)。当接收到一个客户端请求,一个工作线程从工作线程池中被唤醒并处理接收到的请求。当请求被处理完了后,工作线程又被这个线程池回收。这种线程程池的机制对ASP.NET应用程序有如下两个好处:
- 通过线程的重复利用,避免了每次接收到一个新的请求就创建一个新的线程。
- 线程池维护的线程数是固定的,这样线程不会被无限制地创建,减少了服务器崩溃的风险。
一个请求是对应一个工作线程,如果MVC中的action对请求处理的时间很短暂,那么工作线程很快就会被线程池收回以备重用。但如果执行action的工作线程需要调用其他服务(如调用远程的服务,数据的导入导出),这个服务可能需要花很长时间来完成任务,那么这个工作线程将会一直等待下去,直到调用的服务返回才继续工作。这个工作线程在等待的过程中什么也没做,资源浪费了。设想一下,如果这样的action一多,所有的工作线程都处于等待状态,大家都没事做,而新的请求来了又没人理,这样就陷入了尴尬境地。
解决这个问题需要使用异步(asynchronous) Controller,异步Controller允许工作线程在等待(await)的时候去处理别的请求,这样做减少了资源浪费,有效提高了服务器的性能。
使用异步 Controller 需要用到.NET 4.5的新特性:异步方法。异步方法有两个新的关键字:await 和 async。这个新知识点朋友们自己去网上找找资料看吧,这里就不讲了,我们把重点放在MVC中的异步 Controller 上。
在Models文件夹中添加一个 RemoteService 类,代码如下:
using System.Threading; using System.Threading.Tasks; namespace MvcApplication2.Models { public class RemoteService { public async Task<string> GetRemoteDataAsync() { return await Task<string>.Factory.StartNew(() => { Thread.Sleep(2000); return "Hello from the other side of the world"; }); } } }
然后创建一个名为 RemoteData 的 Controller,让它继承自 AsyncController 类,代码如下:
using System.Web.Mvc; using MvcApplication2.Models; using System.Threading.Tasks; namespace MvcApplication2.Controllers { public class RemoteDataController : AsyncController { public async Task<ActionResult> Data() { string data = await new RemoteService().GetRemoteDataAsync(); Response.Write(data); return View("Result", new Result { ControllerName = "RemoteData", ActionName = "Data" }); } } }
运行程序,URL 定位到 /RemoteData/Data,2秒后将显示如下结果:
当请求 /RemoteData/Data 时,Data 方法开始执行。当执行到下面代码调用远程服务时:
string data = await new RemoteService().GetRemoteDataAsync();
工作线程开始处于等待状态,在等待过程中它可能被派去处理新的客户端请求。当远程服务返回结果了,工作线程再回来处理后面的代码。这种异步机制避免了工作线程处于闲等状态,尽可能的利用已被激活的线程资源,对提高MVC应用程序性能是很有帮助的。、
评论精选
提问 by 卤鸽:
IActionInvoker是在Controller.Excute方法中被调用,主要是查询具体的Action 处理方法,其实整个请求的过程都是从MvcHandler进行开始的。这是我的理解。不知正确否?
回答 by Liam Wang
是这么个意思,但不太严谨。确切一点说,Excute 方法是(自定义或默认的)ActionInvoker 的入口函数。 ActionInvoker 必须实现 IActionInvoker 接口来查找和调用 Action 方法。本文没有介绍 MvcHandler 的知识。MvcHandler 是处理Controller的开始,但在MvcHandler 之前还有一个MvcRouteHandler,当请求经过路由解析后,MvcRouteHandler 实例会生成一个 MvcHandler 实例,并把请求交给它。MvcHandler 会从Controller 工厂中获取一个 Controller 实例,然后由 Controller 来具体地处理请求。
原文地址:https://www.cnblogs.com/wfy680/p/12316578.html