用Spring 2.0和AspectJ简化企业应用程序

Spring：简单而强大
Spring的目标是使企业应用程序开发尽可能地简单和高效。这一理论的实例可以从Spring的JDBC、ORM、JMX、依赖注入等方法，以及企业应用程序开发的其他许多重要领域中见到。Spring还区分了使事情简单化和过分单纯化之间的差异。最不可思议的是同时提供了简单化和强大的功能。企业应用程序中复杂性的一个根源来自影响应用程序多个部分的特性和需求的实现。相关于这些特性的代码最终散布在应用程序代码中，使得它更难以添加、维护和理解。Spring 2.0使得以模块化的方式实现这些特性变得更加简单，极大地简化了整体的应用程序代码，并且有时使得在实现没有它的情况下十分痛苦的编码需求变得易如反掌。

事务管理是影响应用程序多个部分的一个特性实例：一般来说所有的操作都在服务层。在Spring中解决这种需求的方式是通过使用AOP。Spring 2.0在它对AOP的支持中提供了一个明显的简化，同时还提供了比Spring 1.x所提供的更多富有表现力的功能。这些改善之处主要来自两个主要的领域：通过使用XML schema极大地简化了配置，以及与AspectJ的整合带来了更好的富有表现力的功能和更简单的advice模型。

在本文中，我将首先介绍在典型的企业应用程序中，Spring AOP和AspectJ适用于什么地方，之后介绍在2.0中新的Spring AOP支持。大部分篇幅用来讲解企业应用程序中AOP的采用路线图，通过大量可以只用AOP实现的特性实例，但是用任何其他的方法进行实现都将非常困难。

简化企业应用程序
典型的企业应用程序——比如一个Web应用程序——由许多层构成。一个包含视图和控制器的Web层，一个表现系统业务接口的服务层，一个负责保存和获取持久化领域对象的数据访问或者存储层，与所有这些层共事的，还有一个核心业务逻辑所在的领域模型。

Web层、服务层和数据访问层有着许多相同的重要特征：它们应该尽可能地瘦，它们不应该包含业务逻辑，并且它们一般通过Spring组装在一起。在这些层中，Spring负责创建对象和配置。领域模型则有些不同：领域对象由程序员利用新的操作器创建（或者利用从数据库中获取的ORM工具进行扩建）。领域对象有许多唯一的实例，它们（可以）有丰富的行为。

服务层可以包含特定于应用程序用例的逻辑，但是所有领域相关的逻辑都应该放在领域模型本身里面。

服务层一般是使用声明式企业服务（例如事务）的地方。声明式的企业服务，例如事务和安全是影响应用程序中多个点的很好的需求实例。事实上，即使你想让（比如）事务划分只在单个地方，将这项功能与你的应用程序逻辑分开，使得代码更加简单，避免不必要的耦合，这也仍然很好。

由于服务对象是Spring管理的bean，Spring AOP天生适合于在这个层中处理需求。事实上，任何人在使用Spring的声明式事务支持时，就已经是在使用Spring AOP了，无论他们是否意识到这一点。Spring AOP很成熟，得到了广泛的应用。它非常适合于Web、服务和数据访问层中受Spring管理的bean，只要你的需求可以通过advice bean方法执行得到处理（且这些层的许多用例都属于这一类）。

当提到影响你领域模型中多个点的需求时，你应用程序的最重要部分——Spring AOP——的帮助就小多了。你可以编程式地使用Spring AOP，但是这样会很难使用，并且还要你自己负责创建代理和管理同一性。AspectJ天生适合于实现影响领域对象的特性。AspectJ方面不需要任何特殊的代理创建，并且可以很恰当地通知运行时在你的应用程序代码中，或者通过你可能使用的框架所创建的对象。当你想要模块化影响你应用程序的所有不同层的行为，或者模块化性能以任何方式感知的行为时，AspectJ也是一种非常好的解决方案。

因此，我们最想要的是一种一致的Spring AOP和AspectJ方法，以便我们可以很容易地一起使用这两种工具，以便如果需求发生变化，你用（比如）Spring AOP开发的能力就可以转移到AspectJ上。无论我们正在使用哪种组合，我们仍然喜欢依赖注入和Spring所提供的配置的所有益处。Spring 2.0中新的AOP支持正好带来了这一点。