.NET中对AOP的研究(系列一)

    前述:这段时间一直在研究AOP，发现真的是一种很好的架构思路，在架构中使用AOP去设计，真正达到松耦合，业务逻辑清晰,易扩展.目前在研究过程中在Unity2.0中都实现了对AOP的支持,当然也可以完全自己去封装以实现AOP.我会在以后的文章中分别对其进行实现,废话不多话,直接开始(由于个人水平有限,有问题请予以指正).

 

1．AOP概念

    AOP是Aspect Oriented Programming的简写，即面向方面编程，其核心内容就是所谓的“横切关注点”。

在OO思想中，继承是一个核心思想.定义一个Interface,由类继承并实现Interface,再由子类继承类.很明显这是一个自上而下的结构,即纵向结构.

但是在软件系统中,有很多模块或者说很多类中需要共享一些行为或方法,那这个行为或方法就存在于不同的模块或类中,这个时候就产生了这种横向结构.

下图就非常清晰的表明了这种横向结构:

 

2．AOP应用场景

  Ø Authentication 权限

  Ø Caching 缓存

  Ø Context passing 内容传递

  Ø Error handling 错误处理

  Ø Lazy loading 懒加载

  Ø Debugging 调试

  Ø logging, tracing, profiling and monitoring 记录跟踪 优化 校准

  Ø Performance optimization 性能优化

  Ø Persistence 持久化

  Ø Resource pooling 资源池

  Ø Synchronization 同步

  Ø Transactions 事务

 

3．为什么要使用AOP

   对于应用软件系统来说，日志操作是一个常见的例子。为了得到好的程序结构，通常使用OO的方法，将会将日志操作封装在一个类中，这个类包含了各种日志读写操作等，例如：

   public class LogOperation {

      public void WriteLog(User currentUser , Model accessModel , OperationType operation)

       {

          ……//日志写入操作

       }

   }

   public class BusinessOperation {

      public void BusinessMethod(User currentUser , Model accessModel , OperationType operation)

       {

          ……//业务逻辑操作

          LogOperation Log = new LogOperation()

          Log.WriteLog();

       }

    }

 

   这种做法在OO设计中，是常见的做法。但是，这种做法会带来以下一些问题：

   1、不清晰的业务逻辑：从某种意义上来说，日志操作并不是业务逻辑执行的一部分，这个工作是属于系统的，但是我们不得不把系统的日志操作和业务逻辑执行过程掺杂在一起，造成代码的混乱。

   2、代码浪费：使用这种方法，我们必须所有的业务逻辑代码中用LogOperation类，使得同样日志操作的代码充斥在整个软件中，显然不是很好的现象。

   3、紧耦合：使用这种方法，我们必须在业务逻辑代码中显式引用LogOperation类，这就造成了业务逻辑代码同LogOperation类的紧耦合，这意味着，当LogOperation发生变化时，需要对WriteLog的方法进行改动时，可能会影响到所有代码。下面所有的问题都是因此而来。

   4、不易扩展：我们只是在业务逻辑中添加了日志操作，哪一天，当我们需要添加额外的功能，例如日志记录功能的时候，我们不得不同样在所有的业务逻辑代码中添加这个功能。

   5、不灵活：有的时候，由于某些特定的需要，我们需要暂时禁止，或者添加某项功能，采用传统的如上述的做法，我们不得不采用修改源代码的方式来实现。

 

   总结:由于以上种种不利原因,我们如何去解决,这时就引出AOP思想,在业务逻辑代码不出现LogOperation的调用,直接使用拦截的方式去调用LogOperation.

 

 

转载于:https://www.cnblogs.com/tangzhenjie/archive/2013/06/06/3117277.html