理解AOP

     过完了十一，经过9月份忙碌的一个月（结婚、装修房子）终于又进入了工作状态。  早先就听说过AOP概念，大概只是知道是“面向方面”，具体什么意思，还真是糊涂！与我在平时的开发中经常要用到的“面向组件”开发几乎混为一谈，比如我们在开发中总会抽取分离出一些功能独立的模块，比如Log  Authorization等，做成公共基础组件，供其它模块使用。这种开发的模式大概多数人都能理解。随后又出来个SOA，SOA当然不是某种开发技术，我认为是一种设计思想。这个SOA再加上AOP就让人糊涂了，SOA还好理解，简单直观的说我们再作新项目就不做各种组件了，而是做成Web Services，将可分离的独立业务处理逻辑做成WS，提供相应的服务。比如我要查某份订单，不需要将查询定单的组件或者它的代理部署到调用的客户端上，只要将ws发布到网上，客户端使用WSDL生成代理类来调用服务。这只是简单的理解！但是很直观，那么AOP是什么意思呢？只看字面的Aspect-Oriented Programming很难搞清楚，经过一上午的查阅资料终于搞清楚了，并且也大概搞清楚我们可以通过WCF Custom Behavior来实现使用WCF来进行AOP式的开发。下面讲述下我对AOP的理解：AOP（Aspect-Oriented Programming，面向方面编程。

举个例子：在开发的过程中应该让软件工程师集中精力去分析和实现业务处理逻辑，对于那些非功能性的需要，我们可以让在这些“方面”的专业的工程师去做。比如：权限审计、日志管理等等“方面”。在AOP以前我们也确实是这么做的，单独的设计log模块，将它做成组件Com+或者WS，当我们要录入一份订单时一般会这样写：
{
     if(Auth(User))//审核用户是否有权限录入订单
    {
          string  strOrderGuid = NewGuid.ToString();
         Order NewOrder = new Order(strOrderGuid ,"布加迪.威龙",1);
         OrderMag.Add(NewOrder );
         Log.AddLog(User,DateTime,"录入订单",strOrderGuid );//记录用户在某个时间录入了一份订单编号
 　}
}
这样的设计最好再加上一个Factory来管理这个log order auth等等。这是没有使用AOP的例子。要做订单录入的功能的工程师必须要在实现录入订单的时候来加入或调用AUTH  LOG等公共组件完成审计和日志再加上自己要负责的那部分业务逻辑（录入订单）。这样一个实现特定的业务逻辑的哥们他还要同时考虑其它非功能性需要。当然这个非功能性的需要是其它同事完成开发的。
现在我们来使用AOP。让每个工程师只关注他要负责的那个“方面”，一个做录入订单的哥们只写订单录入的功能，在订单保存的按钮事件这样编码：
{
     Order NewOrder = new Order(strOrderGuid ,"布加迪.威龙",1);
     OrderMag.Add(NewOrder );
}
这个做订单录入的哥们只负责写好录入订单，审计和日志方面都不用管。那么我们真的不做审计和日志了吗？不是的！我们通过AOP技术截获了.Add(NewOrder )，在add之前作Auth(User)，add之后作Log.AddLog(User,DateTime,"录入订单",strOrderGuid )，截获.Add(NewOrder )方法，分析它的参数NewOrder是否符合有效订单等等。
通过配置系统，我们将整个业务“编织”在一起。每个人只负责某个“方面”，由一个总的配置来管理。

形象的说，没有AOP之间我们的系统是一个“垂直”的，我们通过AOP对系统“水平”切割，分离中各个“方面”。

推荐：AOP技术基础 http://wayfarer.cnblogs.com/articles/241024.html