系统的横向结构(AOP)-Ha_lo-Man
系统的横向结构(AOP) 1． AOP 概念
AOP包含以下主要概念：
事务管理是J2EE应用中横切关注点中一个很好的例子。
Ø Joinpoint连接点：程序执行过程中明确的点，如方法的调用或特定的异常被抛出。
Ø Advice通知：在特定的连接点AOP框架执行的动作。
Ø Pointcut切入点：指定一个通知将被引发的一系列连接点的集合。
Ø Introduction引入：添加方法或字段到通知化类。
Ø IsModified接口，来简化缓存。
Ø Target object目标对象：包含连接点的对象。
Ø AOP proxy AOP代理: AOP框架创建的对象，包含通知。
Ø Weaving织入：组装方面创建通知化对象。
Ø Before通知: 在一个连接点之前执行的通知，但这个通知 不能阻止流程继续执行到连接点（除非它抛出一个异常）。
Ø Throws通知: 在方法抛出异常时执行的通知。
Ø After returning通知: 在连接点正常完成后执行的通知， 例如，如果一个方法正常返回，没有抛出异常。
AOP，给我们的软件设计带来了一个新的视角和软件架构方法。
通常，我们可以在如下情景中使用AOP技术：
Ø Transactions 事务
2． AOP 的使用
为了得到好的程序结构，通常使用OO 的方法，将权限校验过程封装在一个类中，这个类包含了一个校验权限的代码，例如：
// 校验权限 }
然后，在业务逻辑过程中进行如下调用：
// 执行业务逻辑 }
但是，这种做法会带来以下一些问题：
2、代码浪费：使用这种方法，我们必须所有的业务逻辑代码中用Security类，使得同样校验的代码充斥在整个软件中，显然不是很好的现象。
3、紧耦合：使用这种方法，我们必须在业务逻辑代码中显式引用Security类，这就造成了业务逻辑代码同Security类的紧耦合，这意味着，当Security发生变化时，例如，当系统进化时，需要对CheckRight的方法进行改动时，可能会影响到所有引用代码。
4、不易扩展：在这里，我们只是在业务逻辑中添加了权限校验，哪一天，当我们需要添加额外的功能，例如日志记录功能的时候，我们不得不同样在所有的业务逻辑代码中添加这个功能。
5、不灵活：有的时候，由于某些特定的需要，我们需要暂时禁止，或者添加某项功能，采用传统的如上述的做法，我们不得不采用修改源代码的方式来实现。
我们假设有如下一个场景：
由于某些原因，我们需要将库存管理系统单独出售，这就需要我们需要从库存商品报废的业务逻辑中将引用的相关的财务处理逻辑去除，这意味着我们需要修改原有的代码。
问题是，这仍旧不是理想的解决方案。
当为系统增加一个类似的需要灵活处理的部分时，开发人员不得不添加相应的参数，并且修改相应的代码（添加相应的判断代码）。
使用AOP，我们可以通过一种更加自然的方式来实现这个目标。
其次，按照正常的方式，编写财务处理逻辑。
从上面的例子可以看出，采用AOP的好处是，我们可以独立的编写各个业务逻辑，使得系统各个部分之间的耦合度降到最低，然后，可以在系统中根据需要随时组合两个逻辑，而不用修改原来的任何代码。3． AOP 的实现
静态织入方法，一般都是需要扩展编译器的功能，将需要织入的代码，通过修改字节码（Java）或者IL代码（.Net）的方法，直接添加到相应的被织入点；或者，我们需要为原来语言添加新的语法结构，从语法上支持AOP。
动态织入的方法，具体实现方式就有很多选择了。
在Java平台上，可以使用Proxy模式，或者定制ClassLoader来实现AOP功能。
在.Net平台上，要实现AOP的动态织入，归纳起来，可以采用以下几种方法：
关于ContextAttribute的具体使用方法，读者可以参考MSDN等相关资料。
使用Emit来，在运行时刻动态构建被织入代码后的类，当程序调用被织入类时，实际上调用的是被修改后的类。
使用Proxy模式。
所谓 Proxy ，就是“为其他对象提供一种代理以控制对这个对象的访问”。