Spring和AspectJ的领域驱动设计

在JavaCodeGeeks主持的上一篇文章中，我们的JCG合作伙伴 Tomasz Nurkiewicz介绍了使用State设计模式进行领域驱动设计的介绍。在该教程的最后，他承认他省略了如何将依赖项（DAO，业务服务等）注入域对象的过程。但是，他答应在随后的帖子中解释细节。好了，现在该看看如何完成此工作了。托马斯（Tomasz）继续提供非常具有启发性的教程。

让我们看看他怎么说：

（注意：对原始帖子进行了少量编辑以提高可读性）

在开始讨论我们的主要主题之前，我希望您先想一想关于您可以想象的最佳Java EE应用程序设计。不管使用Spring还是EJB3，都没有关系，因为它们非常相似，可能您会建议一种类似于以下的方法。从后端开始，您有：

域对象 ，它们是直接映射到数据库关系的简单POJO。 POJO很棒，因为许多框架都很好地理解了JavaBean样式的属性。
数据访问层 –通常为无状态服务，它们包装数据库访问代码（JDBC，Hibernate，JPA，iBatis或您想要的任何东西），以隐藏其复杂性并提供一定程度的（泄漏）抽象。 DAO之所以出色，是因为它们隐藏了令人讨厌且笨拙的JDBC逻辑（这就是为什么有人质疑使用JPA时对DAO的需求），它充当数据库和对象之间的或多或少的翻译器。
业务服务层 –在域对象上运行的另一组无状态服务。典型的设计引入了一个对象图，这些对象采用或返回域对象并对其执行一些逻辑，同样，通常通过数据访问层访问数据库。服务层很棒，因为它专注于业务逻辑，将技术细节委托给DAO层。
用户界面 –如今，通常是通过网络浏览器。用户界面之所以如此出色是因为……事实如此。

美丽，不是吗？现在睁开眼睛，是时候洗个冷水了。

服务和DAO都是无状态的，因为Spring和EJB3偏爱此类，因此我们学会了使用它。另一方面，POJO是“无逻辑的” –它们仅包含数据，不对其进行操作就保持其状态并且不引入逻辑。如果考虑将“ reservation”域对象引入我们的应用程序，我们会立即想到映射到RESERVATIONS数据库表，ReservationDao，ReservationService，ReservationController等的Reservation POJO。

还是看不到问题吗？您如何形容“对象”？它是一些具有内部（封装）状态的虚拟实体，以及一些具有对该状态的显式访问权限的公共操作。基于对象的编程的最基本概念是将数据和对该数据进行操作的过程放在一起并紧密关闭它们。现在看看您有史以来最好的设计，您真的需要物体吗？这是Spring，EJB3，Hibernate和其他完善框架的秘密。我们所有人下意识地试图忘记的秘密：我们不再是OOP程序员！

POJO不是对象，它们只是数据结构，数据集合。 Getter和Setter不是真正的方法，实际上，您最后一次手工编写它们是什么时候？实际上，自动生成它们（以及在属性更改时重构，添加和删除）的需求有时会令人沮丧。缺省情况下，仅使用具有公共字段的结构会不会更简单？

另一方面，请查看所有这些出色的无状态服务。他们没有任何状态。尽管它们在域对象上运行，但它们不是域对象的一部分，甚至不聚集它们（低内聚性）。所有数据都通过方法参数显式传递。它们也不是对象，它们只是在公共名称空间（对应于类名称）上任意聚集的过程的集合。在合同中，OOP中的方法也是幕后的过程，但是具有对该引用的隐式访问，该引用指向对象实例。每当我们调用ReservationService或ReservationDao明确提供Reservation POJO引用作为参数之一时，我们实际上是在重新发明OOP并手动对其进行编码。

面对现实，我们不是OOP程序员，因为我们需要的一切都是五十年前发明的结构和过程。每天有多少Java程序员在使用继承和多态？上一次编写具有私有状态而没有getter / setter且只有很少方法可以访问的对象的时间是什么时候？上次使用非默认构造函数创建对象的时间是什么时候？

幸运的是，Spring采取了什么措施，它带回了更大的力量。该功能称为AspectJ 。

在上一篇文章中，我创建了一个保留实体，该实体具有三种业务方法：accept（），charge（）和cancel（）。将与域对象有关的业务方法直接放置在该对象中看起来真的很好。无需调用ReservationService.accept（reservation），我们只需运行Reservation.accept（）即可，它更加直观且噪音小。更好的是，编写：

Reservation res = new Reservation()
//...
res.persist()

而不是调用DAO或直接使用EntityManager？我对域驱动设计了解不多，但是我发现这种基本的重构是进入DDD世界（以及返回到OOP）必须走的第一步。

Reservations的accept（）方法最终将需要将一些逻辑委托给外部服务，例如记帐或发送电子邮件。自然，此逻辑不是保留域对象的一部分，应该在其他地方实现（高内聚性）。问题是如何将其他服务注入域对象。当所有服务都由Spring管理时，一切都很简单。但是，当Hibernate自己创建域对象或使用new运算符创建对象时，Spring对此实例一无所知，无法处理依赖项注入。那么，保留POJO如何获得封装必要逻辑的Spring bean或EntityManager？

首先，将@Configurable批注添加到您的域对象中：

@Configurable
@Entity
public class Reservation implements Serializable {//...
}

这告诉Spring保留POJO应该由Spring管理。但是，如上所述，Spring不了解正在创建的Reservation实例，因此没有机会自动装配和注入依赖项。这是AspectJ的用处。您需要做的就是添加：

<context:load-time-weaver/>

到您的Spring XML描述符。这个非常短的XML代码片段告诉Spring它应该使用AspectJ加载时编织（LTW）。现在，当您运行应用程序时：

java.lang.IllegalStateException：ClassLoader [org.apache.catalina.loader.WebappClassLoader]不提供'addTransformer（ClassFileTransformer）'方法。指定一个定制的LoadTimeWeaver或使用Spring的代理启动Java虚拟机：-javaagent：spring-agent.jar
在org.springframework.context.weaving.DefaultContextLoadTimeWeaver中。
setBeanClassLoader（DefaultContextLoadTimeWeaver.java:82）
在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory中。
initializeBean（AbstractAutowireCapableBeanFactory.java:1322）
在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory中。
doCreateBean（AbstractAutowireCapableBeanFactory.java:473）
…另外59个

它将失败……Java不是魔术，因此在继续之前，请先解释一下。在上面添加XML代码段并不能解决任何问题。它只是告诉Spring我们正在使用AspectJ LTW。但是，当应用程序启动时，它不会找到AspectJ代理，并且会适当地告诉我们有关它的信息。如果按照建议将-javaagent：spring-agent.jar添加到我们的JVM命令行参数，会发生什么？这个Java代理仅仅是JVM的插件，它覆盖了每个类的加载。首次加载Reservation类时，代理会发现@Configurable批注并将某些特殊的AspectJ方面应用于该类。

更精确地说：正在修改Reservation类的字节码，从而覆盖所有构造函数和反序列化例程。多亏了这种修改，每当实例化新的Reservation类时，除了正常的初始化之外，Spring提供的方面添加的那些附加例程都将执行依赖项注入。因此，从现在开始，增强的Reservation类是Spring感知的。保留是由Hibernate，Struts2创建还是使用new运算符都没有关系。隐藏的方面代码始终负责调用Spring ApplicationContext，并要求其将所有依赖项注入域对象。让我们将其用于试驾：

@Configurable
@Entity
public class Reservation implements Serializable {@PersistenceContextprivate transient EntityManager em;@Transactionalpublic void persist() {em.persist(this);}
//...
}

这不是一个错误–我将JPA规范中的EntityManger直接注入域对象。我还将@Transactional批注放置在persist（）方法上。在普通的Spring中这是不可能的，但是由于我们使用了@Configurable批注和AspectJ LTW，因此下面的代码是完全有效的，并且可以按预期工作，对数据库发出SQL并提交事务：

Reservation res = new Reservation()
//...
res.persist()

当然，您也可以将常规依赖项（其他Spring Bean）注入到域对象中。您可以选择使用自动装配（ @Autowire或更好的@Resource批注）或手动设置属性。后一种方法为您提供了更多控制权，但是迫使您在域对象中为Spring bean添加setter并定义与域对象相对应的另一个bean：

<bean class=" com.blogspot.nurkiewicz.reservations.Reservation "><!-- ... -->
</bean>

请注意，我没有提供此bean的名称/ ID。如果可以的话，应该将相同的名称传递给@Configurable批注。

一切都像魅力一样运作，但是我们如何在现实生活中使用这一惊人功能？首先，我们必须设置您的单元测试以使用Java代理。在IntelliJ IDEA中，我只是添加了：

-javaagent：D：/my/maven/repository/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar

JUnit运行配置中的“ VM参数”文本字段。如果将其添加到默认值（“编辑默认值”按钮），则此参数将应用于您运行的每个新单元测试。但是配置IDE并不像配置构建工具（希望是Maven）那么重要。首先，您必须确保Spring Java代理已下载且可用。感谢Maven的依赖关系解析，可以通过添加以下依赖关系轻松实现：

<dependency><groupId>org.springframework</groupId><artifactId>spring-agent</artifactId><version>2.5.6</version><scope>test</scope>
</dependency>

测试代码实际上并不需要JAR，但是通过添加此依赖项，我们保证在测试运行之前已下载JAR。然后，对surefire插件配置进行简单的调整：

<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><configuration><forkMode>always</forkMode><argLine>-javaagent:${settings.localRepository}/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar</argLine></configuration>
</plugin>

真的很简单–可以使用maven存储库路径安全地构造spring-agent.jar的位置。此外，还必须设置forkMode以便在执行每个测试之前重新加载类（并导致LTW发生）。我认为配置您的应用服务器和/或启动脚本不需要任何进一步的说明。

这就是通过加载时编织进行Spring和AspectJ集成的全部内容。很少有简单的配置步骤和域驱动设计的全新世界出现。我们的领域模型不再脆弱，实体变得“智能”，业务代码更加直观。最后但并非最不重要的一点–您的代码将是面向对象的，而不是过程性的。

当然，您可能不喜欢加载时编织，因为它会干扰JVM类的加载。还有另一种方法，称为编译时编织，它在编译时而不是在类加载时编织方面。两种方法都有其优缺点，以后我将尝试将它们进行比较。

确实，这是非常有趣的方法。就是这样，我们的JCG合作伙伴 Tomasz Nurkiewicz提供了一个紧凑指南，指导如何使用Spring和AspectJ的加载时间编织方式将依赖项注入域对象。如果您喜欢这个，别忘了分享。编码愉快！

相关文章：