介绍几个JAVA的AOP框架开源项目

基于Java的简单、动态、轻量级、强大的AOP框架。既强大又简单，有助于更容易的集成AOP到新的或已存在的项目中。

AspectWerkz 主要特性： 

1 运行时和加载时字节码修正：你可以在运行时或编译时轻松的改造任何（旧）应用程序或除了rtjar以外的外部类库

2 支持join point模型

3 支持Annotation：匹配JavaDoc和JSR-175，支持用户自定义Annotation

4 支持部署多个Aspect定义文件到部署的应用程序（WEB-INF/aopxml、META-INF/aopxml）

5 Introduction/内类型声明（也称Mixin），也就是具有添加接口和实现到已存在的类中的能力

6 Annotation定义：定义Aspect使用的运行时Annotation（为JSR-175准备）

7 XML定义：定义Aspect使用的XML；XML可以用来精炼、改写和解析Annotation定义

8 插件式Aspect管理器能够和IoC框架（如Spring或PicoContainer）一起工作

9 四种不同的Advice和Introduction部署模型（范围）：perJVM（单模式）、 perClass、perInstance 和perThread 

10 Advice和Introduction能够动态部署、反部署或重新部署

11 高性能，使用JIT编译

12 使用Fine-grained模式语言选择join point

13 所有Advice能够和所有的join point和各种混合类型的pointcut

14 脱机变换（可以用作后处理器）

15 Aspect、Advice和Introduction使用POJO编码 

16 目标类可以是正规的POJO，也就是不需要接口

17 支持通过定义传递参数给Advice和定义可重用的Advice堆栈

18 元数据被加到类中

19 简单的用法和配置

AspectWerkz在Eclipse下的辅助开发插件→

更多AspectWerkz信息

JBoss AOP 

JBoss 40带了一个AOP框架。这个框架和JBoss应用服务器紧密地结合，但是你也能够在你的应用中，单独的运行它。

更多JBoss AOP信息

Nanning 

一个虽然简单但也是一个java开源的AOP框架。名字以中文的拼音拼写就是广西的南宁。

更多Nanning信息

JAC 

JAC (Java Aspect Components)是一个应用服务器。它为Java2平台、用于Java开发的企业开发环境（J2EE）、和基于Web的分布式应用，提供开放式资源的又一个选择（在GNU次常规公共许可证下发布）。JAC包括统一模型语言（UML）IDE，该UML IDE模块化应用商业逻辑并且自动生成和编译纯商业逻辑Java类。这些类，在JAC容器内执行，可从一组技术和/或商业的横切关系（crosscutting concerns）[1] 如数据持久性、认证、配置文件管理、访问权限检测、演示、和负载平衡中无缝地受益。基于面向方面编程技术（AOP）的JAC将这些关系( concerns)[2]从应用程序的核心商业逻辑中分离出来。

更多JAC信息

DynamicAspects 

DynamicAspects能够让你使用java编写的面向切面的程序设计,它使用在Sun JDK 15中介绍的"instrumentation"与"agent",Aspects能够软件各模块之间的关系在运行期安装与使用。

更多DynamicAspects信息

dynaop 

dynaop框架使用一个基于运行时的编程机制将AOP代码插入对象中，而不是返回一个具有特征代码的对象。AOP将是面向对象设计（OO）的一个新的领域。

更多dynaop信息

CAESAR 

CAESAR是一个新的与Java兼容的AOP语言。所有java程序多能使用CAESAR。

更多CAESAR信息

PROSE 

PROSE是一个动态编排(weaving)工具(允许在运行期插入或抽取aspects)。PROSE aspects是规则的Java对象能够被发送到或从网络上的计算机接收。签名可被用于保证它们的完整性。一旦一个aspect插入到JVM中,任何事件的发生将影响在相应aspect advice执行的结果。假如一个aspect从JVM中撤消,aspect代码将被丢弃并且相应的拦截也将不会再发生。PROSE aspects是规则的Java对象能够被发送到或从网络上的计算机接收。签名可被用于保证它们的完整性。一旦一个aspect插入到JVM中,任何事件的发生将影响在相应aspect advice执行的结果。假如一个aspect从JVM中撤消,aspect代码将被丢弃并且相应的拦截也将不会再发生。下图是PROSE的体系结构图：

更多PROSE信息

FastAOP 

FastAOP是一个高性能AOP框架。最初开发该框架是为了支持对大型J2EE应用程序进行性能剖析和监测。它几乎不占用运行时间。FastAOP已经在Websphere和Jboss应用服务器上得到成功测试。

更多FastAOP信息

Plastic 

Plastic是一个构建在ASM 33之上的AOP工具包。支持类的基本加载和实例化。引进新的属性。不需要使用反射就能够访问私有属性和方法。重写属性访问权限。注入属性。Method advice(在调用现在方法之后/之前执行一些逻辑)。<DIV class=date>收录时间：2011-05-25 15:25:03</DIV>

更多Plastic信息

Struts是Apache软件基金下Jakarta项目的一部分。Struts框架的主要架构设计和开发者是Craig RMcClanahan。Struts 是Java Web MVC框架中不争的王者。经过长达九年的发展，Struts已经逐渐成长为一个稳定、成熟的框架，并且占有了MVC框架中最大的市场份额。但是Struts某些技术特性上已经落后于新兴的MVC框架。面对Spring MVC、Webwork2这些设计更精密，扩展性更强的框架，Struts受到了前所未有的挑战。但站在产品开发的角度而言，Struts仍然是最稳妥的选择。

Struts有一组相互协作的类（组件）、Servlet以及jsp tag lib组成。基于struts构架的web应用程序基本上符合JSP Model2的设计标准，可以说是MVC设计模式的一种变化类型。根据上面对framework的描述，很容易理解为什么说Struts是一个web framework，而不仅仅是一些标记库的组合。但 Struts 也包含了丰富的标记库和独立于该框架工作的实用程序类。Struts有其自己的控制器（Controller），同时整合了其他的一些技术去实现模型层（Model）和视图层（View）。在模型层，Struts可以很容易的与数据访问技术相结合，包括EJB，JDBC和Object Relation Bridge。在视图层，Struts能够与JSP, Velocity Templates,XSL等等这些表示层组件相结合。 Spring实际上是Expert One-on-One J2EE Design and Development 一书中所阐述的设计思想的具体实现。在One-on-One 一书中，Rod Johnson倡导J2EE实用主义的设计思想，并随书提供了一个初步的开发框架实现（interface21 开发包）。而Spring 正是这一思想的更全面和具体的体现。Rod Johnson 在interface21 开发包的基础之上，进行了进一步的改造和扩充，使其发展为一个更加开放、清晰、全面、高效的开发框架。

Spring是一个开源框架，由Rod Johnson创建并且在他的著作《J2EE设计开发编程指南》里进行了描述。它是为了解决企业应用开发的复杂性而创建的。Spring使使用基本的JavaBeans来完成以前只可能由EJB完成的事情变得可能了。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。

简单来说，Spring是一个轻量的控制反转和面向切面的容

框架。当然，这个描述有点过于简单。但它的确概括出了Spring是做什么的。 Zend Framework(简写ZF)是由 Zend 公司支持开发的完全基于 PHP5 的开源PHP开发框架，可用于开发 Web 程序和服务，ZF采用 MVC(Model–View-Controller) 架构模式来分离应用程序中不同的部分方便程序的开发和维护。

（MVC框架的详细使用及其相关具体操作可以阅读

参考资料：

视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

模型是自包含的，并且与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。如果把数据库从MySQL移植到Oracle，或者改变基于RDBMS数据源到LDAP，只需改变模型即可。一旦正确的实现了模型，不管数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想能构造良好的松耦合的构件。

重用性高

随着技术的不断进步，需要用越来越多的方式来访问应用程序。MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。由于已经将数据和业务规则从表示层分开，所以可以最大化的重用代码了。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。

生命周期成本低

MVC使开发和维护用户接口的技术含量降低。

部署快

使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。

可维护性高

分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。

有利软件工程化管理

由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。 没有明确的定义

完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。

不适合小型，中等规模的应用程序

花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。

增加系统结构和实现的复杂性

对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

视图与控制器间的过于紧密的连接

视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

一般高级的界面工具或构造器不支持模式

改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，会造成MVC使用的困难。