ASP.Net MVC探索之路 - 不想在多个Action上写同样的FitlerAttribute(上)
(写完本文后,我去下载了ASP.NET MVC 3 RC,发现它对Filter的可控性方面进行了某些增强——不仅仅是针对全局Filter的
以AuthorizeAttribute这个Filter举例,一个Controller有若干个Action,包括登录的Action(如Login)。这时我们有两种方式来实现:
1、重新实现一个IAuthorizationFilter,在里面判断如果是Login这个Action,就不进行验证。然后将这个Filter作为FilterAttribute置于Controller定义上。或者Controller自身实现IAuthorizationFilter。
2、除了Login这个Action之外的所有Action加上个Authorize。
这两种方式虽然能够达到目的,但总觉得不够优雅。
如果我想给所有Action注入一段html到页面底部,这种注入可能是临时的,我必须去修改Controller吗?(ASP.NET MVC 3 可以将Filter加入GlobalFilters集合中)
如果我想动态控制某个Action允许由哪些角色访问,我通过修改Controller能实现吗?
如果我想这时候控制的由哪些角色来访问,需求改变时我想要控制由哪些用户来访问呢?我还得去修改Controller吗?或者增加或修改Filter吗?
在ASP.NET MVC 2 中,以上需求好像都需要重新编译Controller。
这里整理一下我们的需求:能不能增删改Filter时不去修改Controller?能让所有Controller和Action定义处都干干净净的那就最好了。
那就把Filter放在Controller外部来管理,在Action或ActionResult等执行Filter之前保证将需要的Filter准备好就行了。
在解决问题之前,先简单回顾一下Action执行前后发生的事。
我们知道,在ASP.NET MVC中,每一次请求通常都定位到一个具体的Controller的Action中。
在默认情况下,由Action执行器(ControllerActionInvoker去控制Action的执行(或不执行),实际做事的是InvokeAction方法。
InvokeAction方法首先去查找Action(由FindAction方法),如果Action被找到了,会通过反射的方式去检索该Action所属Controller的拥有的Filter以及Action拥有的Filter,如果Controller本身也实现了某些Filter接口,也会被检索到(由GetFilters方法)。将找到的所有Filter放入一个FilterInfo变量中(当然放入FilterInfo变量的Filter是经过排序和重复清理的),FilterInfo中保存的Filter不完全是Action自己的Attribute上定义的。
然后先执行找到的所有IAuthorizationFilter(由InvokeAuthorizationFilters方法)。在InvokeAuthorizationFilters方法中,只要有一个IAuthorizationFilter的ActionResult不为null就会立即返回到调用处,不会执行其他的IAuthorizationFilter了。InvokeAuthorizationFilters执行完成后,InvokeAction方法检测其执行结果,如果ActionResult不为null,则执行该Result,其他的IActionFilter,IActionResult就不管啦,否则InvokeAction方法继续。
接着获取要传给Action的参数集(交给GetParameterValue方法),就执行InvokeActionMethodWithFilters方法,方法名已经足够说明它是干什么的了。
如果一切正常,根据InvokeActionMethodWithFilters方法返回的结果去接着就执行InvokeActionResultWithFilters方法。
在执行InvokeAuthorizationFilters一直到执行InvokeActionResultWithFilters的这一整个过程中如果发生异常,则根据捕获的异常执行InvokeExceptionFilters进行异常处理。
代码
这里需要注意一点:InvokeAction、GetFilters、InvokeAuthorizationFilters、GetParameterValue、InvokeActionMethodWithFilters、InvokeActionResultWithFilters、InvokeExceptionFilters等全是虚方法,除非有足够的原因去继承IActionInvoker重写一个Action执行器,否则我觉得重写某些方法足够满足我们的扩展需求了。
甚至ControllerActionInvoker类本身,在ASP.NET MVC基础架构中也是可以替换的,怎么替换呢?在继承Controller类实现我们自己的Controller时重写CreateActionInvoker方法就可以。
另外还可以在构造Controller对象给它的ActionInvoker属性赋值,这又怎么赋值?重写DefaultControllerFactory创建Controller实例的GetControllerInstance方法。 然后在Applicaion_Start中设置新的ControllerFactor:
ControllerBuilder.Current.SetControllerFactory(new YourControllerFactory());
回到主题。 我们将Filter和Action的对应关系或Filter和Controller的对应关系存于一个集合中并缓存起来。在合适的位置“注入”进去就行了。
从找到Action到执行InvokeAuthorizationFilters之前,必须将IAuthorizationFilter准备好;从找到Action到执行InvokeActionMethodWithFilters内部执行Action之前,必须将IActionFilter准备好;从找到Action到执行InvokeActionResultWithFilters内部执行ActionResult之前,必须将IResultFilter准备好。异常发生InvokeExceptionFilters执行之前,必须将IExceptionFilter准备好。 基于以上几点,我们好像可以在FindAction方法
在GetFilters方法中,我们可以根据当前Action的特征(如方法名,或包括请求方式Get或Post等),在“Filter和Action对应表”进行检索;或者根据当前Controller的特征(类型、完整类名都可以),在"Filter和Controller对应表"中进行检索。将匹配的Filter累加入FilterInfo变量就可以了。
GlobalFilterCollection——所以在此特别说明一下本文目前主要针对的是ASP.NET MVC 2.0 RTM,当然大部分都适用于3.0)
以AuthorizeAttribute这个Filter举例,一个Controller有若干个Action,包括登录的Action(如Login)。这时我们有两种方式来实现:
1、重新实现一个IAuthorizationFilter,在里面判断如果是Login这个Action,就不进行验证。然后将这个Filter作为FilterAttribute置于Controller定义上。或者Controller自身实现IAuthorizationFilter。
2、除了Login这个Action之外的所有Action加上个Authorize。
这两种方式虽然能够达到目的,但总觉得不够优雅。
如果我想给所有Action注入一段html到页面底部,这种注入可能是临时的,我必须去修改Controller吗?(ASP.NET MVC 3 可以将Filter加入GlobalFilters集合中)
如果我想动态控制某个Action允许由哪些角色访问,我通过修改Controller能实现吗?
如果我想这时候控制的由哪些角色来访问,需求改变时我想要控制由哪些用户来访问呢?我还得去修改Controller吗?或者增加或修改Filter吗?
在ASP.NET MVC 2 中,以上需求好像都需要重新编译Controller。
这里整理一下我们的需求:能不能增删改Filter时不去修改Controller?能让所有Controller和Action定义处都干干净净的那就最好了。
那就把Filter放在Controller外部来管理,在Action或ActionResult等执行Filter之前保证将需要的Filter准备好就行了。
在解决问题之前,先简单回顾一下Action执行前后发生的事。
我们知道,在ASP.NET MVC中,每一次请求通常都定位到一个具体的Controller的Action中。
在默认情况下,由Action执行器(ControllerActionInvoker去控制Action的执行(或不执行),实际做事的是InvokeAction方法。
InvokeAction方法首先去查找Action(由FindAction方法),如果Action被找到了,会通过反射的方式去检索该Action所属Controller的拥有的Filter以及Action拥有的Filter,如果Controller本身也实现了某些Filter接口,也会被检索到(由GetFilters方法)。将找到的所有Filter放入一个FilterInfo变量中(当然放入FilterInfo变量的Filter是经过排序和重复清理的),FilterInfo中保存的Filter不完全是Action自己的Attribute上定义的。
然后先执行找到的所有IAuthorizationFilter(由InvokeAuthorizationFilters方法)。在InvokeAuthorizationFilters方法中,只要有一个IAuthorizationFilter的ActionResult不为null就会立即返回到调用处,不会执行其他的IAuthorizationFilter了。InvokeAuthorizationFilters执行完成后,InvokeAction方法检测其执行结果,如果ActionResult不为null,则执行该Result,其他的IActionFilter,IActionResult就不管啦,否则InvokeAction方法继续。
接着获取要传给Action的参数集(交给GetParameterValue方法),就执行InvokeActionMethodWithFilters方法,方法名已经足够说明它是干什么的了。
如果一切正常,根据InvokeActionMethodWithFilters方法返回的结果去接着就执行InvokeActionResultWithFilters方法。
在执行InvokeAuthorizationFilters一直到执行InvokeActionResultWithFilters的这一整个过程中如果发生异常,则根据捕获的异常执行InvokeExceptionFilters进行异常处理。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
public virtual bool InvokeAction(ControllerContext controllerContext, string actionName) {
if (controllerContext == null) {
throw new ArgumentNullException("controllerContext");
}
if (String.IsNullOrEmpty(actionName)) {
throw new ArgumentException(MvcResources.Common_NullOrEmpty, "actionName");
}
ControllerDescriptor controllerDescriptor = GetControllerDescriptor(controllerContext);
ActionDescriptor actionDescriptor = FindAction(controllerContext, controllerDescriptor, actionName);
if (actionDescriptor != null) {
FilterInfo filterInfo = GetFilters(controllerContext, actionDescriptor);
try {
AuthorizationContext authContext = InvokeAuthorizationFilters(controllerContext, filterInfo.AuthorizationFilters, actionDescriptor);
if (authContext.Result != null) {
// the auth filter signaled that we should let it short-circuit the request
InvokeActionResult(controllerContext, authContext.Result);
}
else {
if (controllerContext.Controller.ValidateRequest) {
ValidateRequest(controllerContext);
}
IDictionary<string, object> parameters = GetParameterValues(controllerContext, actionDescriptor);
ActionExecutedContext postActionContext = InvokeActionMethodWithFilters(controllerContext, filterInfo.ActionFilters, actionDescriptor, parameters);
InvokeActionResultWithFilters(controllerContext, filterInfo.ResultFilters, postActionContext.Result);
}
}
catch (ThreadAbortException) {
// This type of exception occurs as a result of Response.Redirect(), but we special-case so that
// the filters don't see this as an error.
throw;
}
catch (Exception ex) {
// something blew up, so execute the exception filters
ExceptionContext exceptionContext = InvokeExceptionFilters(controllerContext, filterInfo.ExceptionFilters, ex);
if (!exceptionContext.ExceptionHandled) {
throw;
}
InvokeActionResult(controllerContext, exceptionContext.Result);
}
return true;
}
// notify controller that no method matched
return false;
}
if (controllerContext == null) {
throw new ArgumentNullException("controllerContext");
}
if (String.IsNullOrEmpty(actionName)) {
throw new ArgumentException(MvcResources.Common_NullOrEmpty, "actionName");
}
ControllerDescriptor controllerDescriptor = GetControllerDescriptor(controllerContext);
ActionDescriptor actionDescriptor = FindAction(controllerContext, controllerDescriptor, actionName);
if (actionDescriptor != null) {
FilterInfo filterInfo = GetFilters(controllerContext, actionDescriptor);
try {
AuthorizationContext authContext = InvokeAuthorizationFilters(controllerContext, filterInfo.AuthorizationFilters, actionDescriptor);
if (authContext.Result != null) {
// the auth filter signaled that we should let it short-circuit the request
InvokeActionResult(controllerContext, authContext.Result);
}
else {
if (controllerContext.Controller.ValidateRequest) {
ValidateRequest(controllerContext);
}
IDictionary<string, object> parameters = GetParameterValues(controllerContext, actionDescriptor);
ActionExecutedContext postActionContext = InvokeActionMethodWithFilters(controllerContext, filterInfo.ActionFilters, actionDescriptor, parameters);
InvokeActionResultWithFilters(controllerContext, filterInfo.ResultFilters, postActionContext.Result);
}
}
catch (ThreadAbortException) {
// This type of exception occurs as a result of Response.Redirect(), but we special-case so that
// the filters don't see this as an error.
throw;
}
catch (Exception ex) {
// something blew up, so execute the exception filters
ExceptionContext exceptionContext = InvokeExceptionFilters(controllerContext, filterInfo.ExceptionFilters, ex);
if (!exceptionContext.ExceptionHandled) {
throw;
}
InvokeActionResult(controllerContext, exceptionContext.Result);
}
return true;
}
// notify controller that no method matched
return false;
}
这里需要注意一点:InvokeAction、GetFilters、InvokeAuthorizationFilters、GetParameterValue、InvokeActionMethodWithFilters、InvokeActionResultWithFilters、InvokeExceptionFilters等全是虚方法,除非有足够的原因去继承IActionInvoker重写一个Action执行器,否则我觉得重写某些方法足够满足我们的扩展需求了。
甚至ControllerActionInvoker类本身,在ASP.NET MVC基础架构中也是可以替换的,怎么替换呢?在继承Controller类实现我们自己的Controller时重写CreateActionInvoker方法就可以。
另外还可以在构造Controller对象给它的ActionInvoker属性赋值,这又怎么赋值?重写DefaultControllerFactory创建Controller实例的GetControllerInstance方法。 然后在Applicaion_Start中设置新的ControllerFactor:
ControllerBuilder.Current.SetControllerFactory(new YourControllerFactory());
回到主题。 我们将Filter和Action的对应关系或Filter和Controller的对应关系存于一个集合中并缓存起来。在合适的位置“注入”进去就行了。
从找到Action到执行InvokeAuthorizationFilters之前,必须将IAuthorizationFilter准备好;从找到Action到执行InvokeActionMethodWithFilters内部执行Action之前,必须将IActionFilter准备好;从找到Action到执行InvokeActionResultWithFilters内部执行ActionResult之前,必须将IResultFilter准备好。异常发生InvokeExceptionFilters执行之前,必须将IExceptionFilter准备好。 基于以上几点,我们好像可以在FindAction方法
GetFilters方法、InvokeAuthorizationFilters方法、InvokeActionResultWithFilters方法和GetFilters方法内部,或InvokeExceptionFilters执行前将必要的Filter准备好就可以了。当然,最合适的莫过于GetFilters方法了。
在GetFilters方法中,我们可以根据当前Action的特征(如方法名,或包括请求方式Get或Post等),在“Filter和Action对应表”进行检索;或者根据当前Controller的特征(类型、完整类名都可以),在"Filter和Controller对应表"中进行检索。将匹配的Filter累加入FilterInfo变量就可以了。
感兴趣的可以去看看Oxite ,它实现了本章提到的一部分的需求。