从抽象谈起(三):AOP编程和ASP.NET MVC

AOP(Aspect oriented programming)面向切面编程。说成切面不容易理解,代码哪里有切面?又不是三维物体。概念不管,我们从其思想来理解这个名词吧。 AOP的主要思想是把相同、相似的并且零散的逻辑抽离出来,统一处理;这样不仅维护起来方便,也让代码更加关注自己本身,清晰明了。

比如我们常见的权限检查、日志记录、异常处理等都是散乱在系统各个地方,比如发表一篇文章的代码:

  1. public void Post(Article article)  
  2. {  
  3.     if(currentUser is null)  
  4.         throw new AuthException("您还没有登录");  
  5.     else  
  6.         ArticleManager.Save(article);  
  7. }  

本来一句话ArticleManager.Save就能搞定的事情,现在要加上if else 还要处理异常,代码显得异常难看也难以维护。假如换成

  1. [Authorize]  
  2. public void Post(Article article)  
  3. {  
  4.     ArticleManager.Save(article);  
  5. }  

用AuthroizeAttribute来处理权限问题,这样代码清晰很多,而且可以复用这个Attribute,这么好的思想就是AOP思想。
当然Attribute只是一种实现方式,Attribute也是调用Post方法前,通过反射得到Attribute,然后执行其代码,
平时我们用的最多的AOP就在ASP.NET MVC框架里,这个AuthorizeAttribute就是MVC自带的。我们可以重写他的一些方法达到自己想要的功能(比如权限等级等)。

再举一个处理异常的例子,如果我们有一个统一的处理异常的逻辑,那么就可以在逻辑代码里不用try/catch,而是直接throw exception,这会让代码更加整洁。
(PS:比不是说有了统一处理就再也不用try/catch了,有些异常该吃掉的还是要吃掉,这要看具体的业务需求。另外捕获不到的异常比如线程里的要注意catch。)
比如例子:

  1. public void Post(Article article)  
  2. {  
  3.     if(String.IsNullOrEmpty(article.Title))  
  4.     {  
  5.         throw new ArgumentMissException("title");  
  6.     }  
  7.     ...  
  8.     ArticleManager.Save(article);  
  9. }  
  10.   
  11. protected override void OnException(ExceptionContext filterContext)  
  12. {  
  13.     //..异常处理代码  
  14. }  

而只要重写MVC提供好的OnException方法就能处理所有的异常,或者是展现给用户友好的错误界面,或者是发送异常日志都很方便,而不用在每个地方都写处理的代码。
延伸考虑一下,如果统一处理异常信息,那么对异常的善后处理的把握就要看异常类的设计和运用了。

另外,再看上面的代码,如果有多个地方需要Post(Article),但又完全不一致,可是字段检查是一致的,那就会造成字段检查的代码重复,这种情况要么用一个单独的方法来验证Article的有效性,然后各个地方调用,要么就用MVC提供的ModelBinder,这也是通过参数的Attribute来实现的AOP方法;MVC考虑的太周到了,不得不赞。

  1. public void Post([ArticleBinder]Article article)  
  2. {  
  3.     //这里就不需要再写关于Article的验证代码了  
  4.     ArticleManager.Save(article);  
  5. }  
  6.   
  7. public class ArticleBinderAttribute : CustomModelBinderAttribute  
  8. {  
  9.     class ArticleBinder : IModelBinder  
  10.     {  
  11.         public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)  
  12.         {  
  13.             //虽然自定义了binder很惬意,但这里获取参数值时就没有用Action的参数那么舒服了。  
  14.             var title = controllerContext.RouteData.Values["title"].ToString();  
  15.             if (string.IsNullOrEmpty(title))  
  16.             {  
  17.                 throw new ArgumentNullException("title");  
  18.             }  
  19.             return new Article  
  20.             {  
  21.                 Title = title  
  22.             };  
  23.         }  
  24.     }  
  25.   
  26.     public override System.Web.Mvc.IModelBinder GetBinder()  
  27.     {  
  28.         return new ArticleBinder();  
  29.     }  
  30. }  

  

运用框架提供的AOP很简单也很惬意,但我们在用别人的框架时不能只做应用级程序员,我们要领会其思想,掌握其本质,明白其实现。
所幸,MVC是开源的,我们可以看他的源代码,关注提供AOP的地方。

代码的设计或者说框架的设计,总是想让代码写起来干净利落,松耦合,不拖泥带水。
所以清晰的设计就是从程序的开始,一步步规划其运行步骤,并在适当的地方提供一些供用户处理方法。框架就是把用户框在自己设定的圈子里,但又尽可能的给用户自由。
我们看MVC的大致流程,
1、从输入Url回车那一刻起,先是通过UrlRouting路由,来判断用户访问哪个Controller/Action;
2、通过controllerfactory获取具体的controller实例,用户可自定义factory。
3、通过actioninvoke调用action,在调用之前需要先获取action的filter,这些filter就是AOP的拦截器。用户都可以自定义各种filter(就是自定义的attribute)。
4、根据执行顺序执行action和filter,onactionexecuting、onactionexecuted等。
5、找到action对应的view,用户可自定义viewenginer。
6、呈现页面结束。

当出错的时候invoke的catch调用onexception的用户的实现。

我本想罗列一些MVC的源码,但感觉没必要,有心人自己去下载看吧。如果不清楚的可以加群交流。


就是这样简单,AOP的思想是想把和当前逻辑不相干的代码抽离的一种实现,我们如果追求代码的美感,就会更加在意整体代码的设计,AOP通常用于一个系统的外围搭建处。
只有我们把架子、外围都搭建的漂亮,代码写起来才更美。

posted @ 2013-08-15 14:47  君之蘭  阅读(6441)  评论(4编辑  收藏  举报