ASPNET MVC设计的主要原则之一是可扩展性处理管线（processing pipeline）上的所有（或大多数）东西都是可替换的因此如果您不喜欢ASPNET MVC所使用的约定（或缺乏某些约定）您可以创建自己的服务来支持您的约定并将其注入到主管线中
在本文中我们将从管线开始直到视图呈现逐一向您展示每个ASPNET MVC开发者都必须了解个扩展点
ASPNET MVC扩展之RouteConstraint
通常情况下你可以使用正则表达式对url参数进行约束但如果您的约束不仅仅取决于单一参数您可以实现 IRouteConstrains的方法并在其中添加你的验证逻辑
比如对日期的验证url中可能会包含年月日而你需要验证这三者是否可以组合成一个有效的日期
ASPNET MVC扩展之RouteHandler
RouteHandler是在路由选择之后进行处理的组件它并不仅仅针对ASPNET MVC显然如果您改变了RouteHandler那么对请求的处理将不再使用ASPNET MVC但这在您使用其他HttpHandler或经典的WebForm进行路由处理时却是非常有用的
ASPNET MVC扩展之ControllerFactory
ControllerFactory是基于路由的组件它选择正确的controller并对其实例化 default factory会查找实现了IController并且以Controller结尾的类然后通过反射使用无参构造函数进行实例化
但如果您希望使用依赖注入就不能再使用default factory而必须使用支持IoC的controller factoryMvcContrib和Ninject Controller Factory都包含支持IoC容器的controller factory
ASPNET MVC扩展之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
ASPNET MVC扩展之ActionMethodSelectorAttribute
使用默认的action invoker时action的选择是基于名称的您也可以实现自己的Method Selector以改善对于action的选择在框架中已经包含了AcceptVerbs特性它允许您指定使用哪一个HTTP Verb来处理action的响应
例如您也许会希望基于浏览器所支持的语言或浏览器类型（如移动设备的浏览器或桌面浏览器）来进行action 的选取
ASPNET MVC扩展之AuthorizationFilter
这种过滤器是在action执行之前执行的用来确保请求是有效的
框架中已经包含了一些autorization过滤器最有名的莫过于Authorize特性它用来检查当前 用户是否允许执行该action另一个是用来阻止CSRF攻击的ValidateAntiForgeryToken如果您希望实现自己的 authorization那么必须实现接口例如日期中的小时
ASPNET MVC扩展之ActionFilter
Action Filters在action执行前后执行OutputCache过滤器是几个核心过滤器之一这可能是您最有可能使用的扩展点并且在我看 来controller只关心它的主要工作而view所需要的所有其他数据都必须从action过滤器内部获取这样的实现对于一个组织良好的 view来说是十分关键的
ASPNET MVC扩展之ModelBinder
默认的model binder使用参数名称进行HTTP参数到action方法参数的映射例如http参数useraddresscity将映射到方法参数 user的Address属性的City属性DefaultModelBinder也同样适用于数组和其他列表类型
更进一步来说例如您可能希望从数据库中进行检索直接根据person的id将其转换为Person对象 Timothy Khouri（网名SingingEels）在他的文章Model Binders in ASPNET MVC中更好的阐述了这种方法他的代码基于Preview 但其理念是一样的
ASPNET MVC扩展之ControllerBase
所有的Controller均继承自基类Controller要想在action中封装自己的逻辑和约定创 建自己的父类使所有Controller继承自该类是一种很好的方式
ASPNET MVC扩展之ResultFilter
与ActionFilter类似ResultFilters在ActionResult前后执行 OutputCache过滤器也可以作为ResultFilter的示例另外比较常用的诠释这种过滤器的示例是日志记录如果您希望在页面返回给用户 时记录日志可以编写自定义的RenderFilter在ActionResult执行之后记录日志
ASPNET MVC扩展之ActionResult
ASPNET MVC提供了很多result用来呈现视图JSON纯文本文件并重定向到其他action如果您需要其他类型的result可以自定义 ActionResult并实现ExecuteResult方法例如如果您希望将PDF文件作为结果发送您需要使用PDF库编写能够生成PDF的 ActionResult
ASPNET MVC扩展之ViewEngine
您可能不需要编写自己的view engine但您也许可以考虑使用其他引擎来替代默认的WebForm view engine在我看来最有趣的引擎就是Spark
如果您确实希望编写自己的view engine可以看一下Brad Wilson的文章: Partial Rendering & View Engines in ASPNET MVC
ASPNET MVC扩展之HtmlHelper
视图必须十分简单整洁它们只能包含html标记并调用HtmlHelper的辅助方法视图中不能包含任何代 码所以辅助方法必须十分方便使您可以将代码从视图中提取出来放到一个可测试的环境中去正如Rob Conery所说如果有if就构造辅助方法（If theres an IF make a Helper）
什么是HtmlHelper辅助方法？其实就是HtmlHelper类的扩展方法这是唯一的要求
你可以从Rob的文章Avoiding Tag Soup中了解到为什么说HtmlHelper是封装视图中代码的好方法
在您的应用中该使用哪个呢？
正如您所猜测的那样并不是所有的应用都需要扩展以上的个扩展点最可能在所有应用中进行扩展的是 ActionFilter和HtmlHelper另外您很可能会使用其他人编写的扩展如使用了IoC容器的ControllerFactory或用 来摆脱WebForm的ViewEngine
但是学习这些扩展点并进行尝试是十分重要的这样您才会做出选择并随时准备在必要的时候使用这些强大的扩展 点下周我将发表一些文章来阐述如何使用这些扩展点
