ASP.NET MVC中你必须知道的13个扩展点

     ScottGu在其最新的博文中推荐了Simone Chiaretta的文章13 ASP.NET MVC extensibility points you have to know，该文章为咱们简单介绍了ASP.NET MVC中的13个扩展点。Keyvan Nayyeri（与Simone合著了Beginning ASP.NET MVC 1.0一书）又陆续发表了一些文章，对这13个扩展点分别进行深刻的讨论。我将在之后的随笔中对这些文章逐一进行翻译，但愿能对你们有所帮助。

     ASP.NET MVC设计的主要原则之一是可扩展性。处理管线（processing pipeline）上的全部（或大多数）东西都是可替换的。所以，若是您不喜欢ASP.NET MVC所使用的约定（或缺少某些约定），您能够建立本身的服务来支持您的约定，并将其注入到主管线中。

     在本文中，咱们将从管线开始直到视图呈现，逐一贯您展现每一个ASP.NET MVC开发者都必须了解13个扩展点。

1.RouteConstraint

     一般状况下你可使用正则表达式对url参数进行约束，但若是您的约束不只仅取决于单一参数，您能够实现IRouteConstrains的方法，并在其中添加你的验证逻辑。

     好比对日期的验证，url中可能会包含年、月、日，而你须要验证这三者是否能够组合成一个有效的日期。

2.RouteHandler

     RouteHandler是在路由选择以后进行处理的组件，它并不只仅针对ASP.NET MVC。显然，若是您改变了RouteHandler，那么对请求的处理将再也不使用ASP.NET MVC，但这在您使用其余HttpHandler或经典的WebForm进行路由处理时倒是很是有用的。

3.ControllerFactory

     ControllerFactory是基于路由的组件，它选择正确的controller并对其实例化。default factory会查找实现了IController而且以Controller结尾的类，而后经过反射使用无参构造函数进行实例化。

     但若是您但愿使用依赖注入，就不能再使用default factory，而必须使用支持IoC的controller factory。MvcContrib和Ninject Controller Factory都包含支持IoC容器的controller factory。

4.ActionInvoker

     ActionInvoker顾名思义是负责调用（invoke）action的。默认的action invoker经过方法名、action名或其余可能的selector attribute来查找action，而后调用action方法以及定义的filter，最终执行获得action result。

     你会发现大部分执行管线存在于ControllerActionInvoker类的逻辑之中。所以，若是但愿改变这些约定，如action方法的选择逻辑、http参数映射到action参数的方式、选择和执行filter的方式等，您须要扩展该类并重写须要修改的方法。

     能够参阅NinjectActionInvoker I developed to allow injection of dependencies inside filters。

5.ActionMethodSelectorAttribute

     使用默认的action invoker时，action的选择是基于名称的。您也能够实现本身的Method Selector以改善对于action的选择。在框架中已经包含了AcceptVerbs特性，它容许您指定使用哪个HTTP Verb来处理action的响应。

     例如，您也许会但愿基于浏览器所支持的语言或浏览器类型（如移动设备的浏览器或桌面浏览器）来进行action的选取。

6.AuthorizationFilter

     这种过滤器是在action执行以前执行的，用来确保请求是有效的。

     框架中已经包含了一些autorization过滤器，最有名的莫过于Authorize特性，它用来检查当前用户是否容许执行该action。另外一个是用来阻止CSRF攻击的ValidateAntiForgeryToken。若是您但愿实现本身的authorization，那么必须实现接口。例如，日期中的小时。

7.ActionFilter

     ActionFilter在action执行先后执行。OutputCache过滤器是几个核心过滤器之一。这多是您最有可能使用的扩展点，而且在我看来，controller只关心它的主要工做，而view所须要的全部其余数据都必须从action过滤器内部获取，这样的实现对于一个组织良好的view来讲，是十分关键的。

8.ModelBinder

     默认的model binder使用参数名称进行HTTP参数到action方法参数的映射。例如，http参数user.address.city将映射到方法参数user的Address属性的City属性。DefaultModelBinder也一样适用于数组和其余列表类型。

     更进一步来讲，例如，您可能但愿从数据库中进行检索，直接根据person的id将其转换为Person对象。Timothy Khouri（网名SingingEels）在他的文章Model Binders in ASP.NET MVC中更好的阐述了这种方法。他的代码基于Preview 5，但其理念是同样的。

9.ControllerBase

     全部的Controller均继承自基类Controller。要想在action中封装本身的逻辑和约定，建立本身的父类使全部Controller继承自该类，是一种很好的方式。

10.ResultFilter

     与ActionFilter相似，ResultFilter在ActionResult先后执行。OutputCache过滤器也能够做为ResultFilter的示例。另外，比较经常使用的诠释这种过滤器的示例是日志记录。若是您但愿在页面返回给用户时记录日志，能够编写自定义的RenderFilter，在ActionResult执行以后记录日志。

11.ActionResult

     ASP.NET MVC提供了不少result用来呈现视图、JSON、纯文本、文件并重定向到其余action。若是您须要其余类型的result，能够自定义ActionResult，并实现ExecuteResult方法。例如，若是您但愿将PDF文件做为结果发送，您须要使用PDF库编写可以生成PDF的ActionResult。又如RSS feed，可参见how to write a RssResult in this post。

12.ViewEngine

     您可能不须要编写本身的view engine，但您也许能够考虑使用其余引擎来替代默认的WebForm view engine。在我看来，最有趣的引擎就是Spark。

     若是您确实但愿编写本身的view engine，能够看一下Brad Wilson的文章: Partial Rendering & View Engines in ASP.NET MVC。

13.HtmlHelper

     视图必须十分简单整洁，它们只能包含html标记并调用HtmlHelper的辅助方法。视图中不能包含任何代码，因此辅助方法必须十分方便，使您能够将代码从视图中提取出来，放到一个可测试的环境中去。正如Rob Conery所说：若是有if，就构造辅助方法（If there's an IF, make a Helper）。

     什么是HtmlHelper辅助方法？其实就是HtmlHelper类的扩展方法，这是惟一的要求。

     你能够从Rob的文章Avoiding Tag Soup中了解到为何说HtmlHelper是封装视图中代码的好方法。

在您的应用中该使用哪一个呢？

     正如您所猜想的那样，并非全部的应用都须要扩展以上的13个扩展点。最可能在全部应用中进行扩展的是ActionFilter和HtmlHelper。另外，您极可能会使用其余人编写的扩展，如使用了IoC容器的ControllerFactory或用来摆脱WebForm的ViewEngine。

     可是，学习这些扩展点并进行尝试是十分重要的，这样您才会作出选择，并随时准备在必要的时候使用这些强大的扩展点。

 

参考连接：http://www.cnblogs.com/kirinboy/archive/2009/06/01/13-asp-net-mvc-extensibility-points-you-have-to-know.html