从贫血领域模型到丰富领域模型 第二部分

4.重构到丰富领域模型构架<o:p></o:p>

4.1.技术方案<o:p></o:p>

为了简便起见，下文中使用A和B这两个别名分别代表“贫血领域模型”和“丰富领域模型”，使用名称空间表示模型中的层，如B::应用层表示丰富领域模型的应用层。

通过前面的比较，可以很容易的得到下面转换的方案：

1）保持表现层不变

2）分离出来应用层。从A::领域层移出应用逻辑形成B::应用层。

3）重构一个纯粹的领域层。将A::领域层的领域逻辑部分进行分解：

    # 将概念性的逻辑重构到B::领域层.实体和B::领域层.值对象；
    # 将操作性逻辑重构到B::领域层.服务；
    # 将数据源访问抽象为存储库接口，存储库的实现由Ioc容器注入。
<!----><!---->

4）重构数据访问对象，使其实现领域层的存储库接口。

5）基础设施层保持不变。

不多做解释，下面通过代码进行说明。

4.2. 示例代码<o:p></o:p>

还是前面的在线购物网站，但这次使用了一个稍微能体现领域逻辑的用例：列出与当前产品相关的其他产品。

1）页面发出请求

下面是一个可能的JSF代码片断：

<h:commandLink action="#{product.related}" value="#{相关产品}">
    <f:param name="productid" value="#{product.id}" />
<!---->h:commandLink>

2）代理到控制器

与前面一样，只是增加了一个响应查询相关产品的响应事件：

package yourpackage.action;<o:p></o:p>

......<o:p></o:p>

public class ProductAction extends BaseAction {<o:p></o:p>

         //通过依赖注入的服务<o:p></o:p>

private ProductService productService;<o:p></o:p>

//作为模型对象的领域对象<o:p></o:p>

private Product product;<o:p></o:p>

private Integer id;<o:p></o:p>

//响应查看产品信息的事件<o:p></o:p>

public String edit() {<o:p></o:p>

        product = productService.getProduct(id);<o:p></o:p>

return “product”;  //JSF将其解析为product.xhtml视图<o:p></o:p>

}<o:p></o:p>

//响应查询相关产品的事件<o:p></o:p>

public String related() {<o:p></o:p>

        product = productService.getRelatedProduct(id);<o:p></o:p>

return “products”;  //JSF将其解析为products.xhtml视图<o:p></o:p>

}<o:p></o:p>

<o:p> </o:p>

}

3）领域层的服务

与前面贫血领域模型的代码中有一些区别：用Reporsitory代替了Dao，并增加了一个获取产品信息的领域逻辑方法。

package yourpackage.service;

......

public class ProductServiceImpl extends BaseService implements ProductService {

    //通过依赖注入的存储库实现

private ProductRepository productRepository;

<o:p> </o:p>

//获取产品信息的领域逻辑方法

public Product getProduct(Integer id) {

        return productRepository.getProduct(id);

}

//获取产品信息的领域逻辑方法

public Product getRelatedProduct(Integer id) {

        Product product= productRepository.getProduct(id);

return product.getRelated();

    }

}

4）领域层的实体

一切魔法都发生在这里！

现在我们的实体除了封装数据外，还有了一个真正的领域方法：getRelated()。

package yourpackage.model;

<o:p> </o:p>

import org.springframework.beans.factory.annotation.Configurable;

import org.springframework.beans.factory.annotation.Autowire;

......

<o:p> </o:p>

@Entity

@Configurable(autowire=Autowire.BY_TYPE ,dependencyCheck=true)

public class Product {

<o:p> </o:p>

//通过依赖注入的存储库实现

private ProductRepository repository;   

public void setProductRepository(ProductRepository repository) {

    this.repository = repository;

}

<o:p> </o:p>

       @Id @GeneratedValue(strategy=GenerationType.AUTO)

       @Column(name="Id")

       public Long getId() {

              return id;

       }

<o:p> </o:p>

       @Column(name="Name", length=30, nullable=false)

       public String getName() {

              return name;

       }

<o:p> </o:p>

    //这是一个领域逻辑方法

public List <product> getRelated() {</product>

    return repository.getRelated(getId());

}

}

下面来解释一下魔法的背后到底发生了什么。

从Spring 2.0开始，在AspectJ的帮助下，提供了一个annotation驱动的方面用于任何对象的依赖注入，即使这些对象并不是由容器所创建。最典型的就是由Hibernate管理的领域对象。

@ Configurable是一个标记性的Annotation，告诉Spring，在实例化这个类的时候需要使用一个原型。autowire=Autowire.BY_TYPE则告诉Spring，这个原型是根据类型自动创建的（autowiring），这避免了在Spring配置文件中显式的定义一个Product类型的Bean。另外还需要通过dependencyCheck=true来告诉Spring，在新建Product类型的实例时进行依赖检查。由于我们的Product中出现了setProductRepository()，而Spring恰好发现了一个名为productRespository的Bean：

<bean id="productRepository" class="yourpackage.dao.ProductRepositoryImpl" />

于是就将这个Bean的实例设置到Product对象的repository。这就是大家早已熟悉的依赖注入，只不过这一次发生在了领域对象的身上。

这一切之所以能够发生，是因为背后一个叫做AnnotationBeanConfigurerAspect的方面在起作用。使用该类需要引入Spring发行包中的spring-aspects.jar，并且在配置文件中进行如下定义：

<aop:spring-configured/>

最后要做的一件事是，必须有某种机制使得被注解的类能够被AspectJ weaver织入。一种方法是用AspectJ的ajc编译器对代码进行预编译，另外一种方式是使用AspectJ Load-time weaving (LTW)。

如果在Java 5环境使用LTW，需要在类路径下的META-INF目录中编写一个名为aop.xml的文件，以告诉AspectJ对那些类进行织入处理：

aop.xml 代码

  "-//AspectJ//DTD//EN"    "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">

<aspectj>
  <weaver>
    <include within="yourpackage.domain.Product"/>
  <!---->weaver>
<!---->aspectj>

然后，需要在JVM加载参数中指定下面的内容：

-javaagent: <path-to-ajlibs>/aspectjweaver.jar</path-to-ajlibs>

现在可以说大功告成了。

5）DAO对象

现在DAO需要实现的接口变成了领域层的ProductRepository：

package yourpackage.dao;

<o:p> </o:p>

import yourpackage.domain;

......

public class ProductDaoJpa extends BaseDaoJpa implements ProductRepository {

       public Product getProduct(Integer id) {

              return (Product) getJpaTemplate().find(Product.class, id);;

       }

<o:p> </o:p>

       public Product getRelatedProduct(Integer id) {

              //这里是具体的实现代码

       }

}

5.结论<o:p></o:p>

要构建一个纯粹的领域模型，往往需要在领域对象中直接使用外部服务，如数据库访问，外部资源，或其他必要的服务。在没有强大的Annotation、AOP及DI技术的支持下，这些外部服务或资源很难被注入到领域对象中，由此形成了贫血模型的设计风格。

特别地，对于Spring用户来说，在2.0版发布之后，问题的解决变得更容易一些。利用Spring集成的AspectJ实现向领域对象进行依赖注入，可以使领域对象可以表达更丰富的逻辑，从而过渡到丰富领域模型。在这个关键问题解决之后，剩下的问题也就迎刃而解了。

评论

5 楼 ray_linn 2008-10-31  

其次 AOP的引入会不会带来测试上麻烦~~~

4 楼 ray_linn 2008-10-31  

ASPECTJ有两大缺点：

1. 静态织入ajc十分不稳定，平均每编译5次就有出现内存不足或者其他莫名奇妙的错误。
2. AspectJ Load-time weaving，对不少项目来说不具备意义，尤其是对需要发布项目到公用主机上的项目，添加一行参数可能被对方所拒绝。

3 楼 ray_linn 2008-10-30  

ASPJECTJ的注入简直是...一堆破旧的陈货。在Eclipse上一但enabled了这个，就意味着你的系统将不停的死机和耗费内存。


ASPJECTJ的注入远不入.net里的扩展方法来得漂亮，把贫血模型的operation attached到domain上，就成了。

2 楼 uiafzhdl 2006-12-22  

引用

江南白衣     2 小时前

非常好~~

致谢了。
刚看到一篇不错的blog，里面对容器外的依赖注入方式有更全面的讨论，分享一下：
http://igorstoyanov.blogspot.com/2005/12/dependency-injection-or-service.html

1 楼 江南白衣 2006-12-22  

非常好~~