贫血的Domain Model

最新推荐文章于 2024-07-07 03:41:52 发布

iteye_2631

最新推荐文章于 2024-07-07 03:41:52 发布

阅读量140

点赞数

分类专栏：技术文章标签： Hibernate DAO Linq Rails IOC

技术专栏收录该内容

30 篇文章 0 订阅

订阅专栏

好老的话题啦。拿出来炒炒冷饭。各位见谅。
——————————————————————
Domain Model贫血是说属于Domain Model的逻辑没有放在Domain Model中。那是哪些逻辑没有放到Domain Model中，从而导致贫血一说呢？原因有很多，但是我认为最主要是Service中的那些逻辑。而这些逻辑又有一个共同的特点就是依赖于DAO，或者说需要查询数据库。Robbin的帖子：http://www.iteye.com/topic/57075，举了一个很好的例子。我取其中的一个部分在这里做演示用。

[code]
public class Employee {
private Set<Task> tasks = new HashSet<Task>();
}
[/code]

[code]
public class Task {
private String name;
private Employee owner;
private Date startTime;
private Date endTime;
}
[/code]

这是一个很简单的一对多的关系。现在要查找指定员工的处理中的任务。如果忽略数据库的存在，我想大部分的同志都会这么实现：

[code]
public class Employee {
private Set<Task> tasks = new HashSet<Task>();
public Set<Task> getProcessingTask() {
...
}
}
[/code]

这也符合OO数据隐藏的基本原则。但是如果有数据库存在，怎么写就不那么容易决定了。如果没有Hibernate这样的ORM。那肯定是：

[code]
public class TaskDAO {
public Set<Task> getProcessingTasks(Employee employee) {
...//sql
}
}
[/code]

那我觉得，这就导致了Domain Model的失血。因为没有数据库的时候，这这个方法本来应该在Employee上的，而不是在DAO上的。
如果有Hibernate呢？是不是我就可以把这段代码写到Employee里面去呢？

[code]
@Entity
public class Employee {
@OneToMany
private Set<Task> tasks = new HashSet<Task>();
public Set<Task> getProcessingTask() {
...
}
}
[/code]

还是有问题。因为访问tasks的时候，Hibernate会去加载数据。getProcessingTask会便利所有的task。如果task的数量很多，这降极大的影响性能。所以为了能够享受到关系数据库查询速度的好处，我们要还要利用SQL。于是DAO又再次地找到了自己的位置。那么怎么解决这个问题呢？在http://www.iteye.com/topic/57075的回帖中nihongye同学提出了一个解决方案。本质来说就是不让hibernate来映射tasks，改由查询来获得。加上Spring支持的@Configurable标记，我们可以把代码写成这样

[code]
@Entity
@Configurable
public class Employee {
private TaskDao dao;
public Set<Task> getProcessingTask() {
return dao.getProcessingTask(this);
}
public void setTaskDao(TaskDao dao) {
this.dao = dao;
}
}
[/code]

我们当然还可以把TaskDao替换成变的形式。比如http://www.iteye.com/topic/65406里firebody提到的那样。但是本质上来说，都是让Employee能够直接去使用Hibernate做查询。但是坏处是给Domain纯净分子的口实。虽然，我认为和ActiveRecord类似，entity绑定在数据库上没啥不好。另外一个缺点就是，要么仍然有一个Dao来封装查询逻辑的实现，要么Employee的实现中出现太多的hibernate api，而且写法复杂。这也就是Robbin一再强调，ActiveRecord那样的api在Java世界中不是不可以，而是实现复杂难度高的原因。注入可以解决问题，但是对Hibernate的依赖强而且写法丑陋。
那么有没有更优美的方案呢？有：

[code]
public class Employee {
private RichSet<Task> tasks = new DefaultRichSet<Task>();
public RichSet<Task> getProcessingTasks() {
return tasks.find("startTime").le(new Date()).find("endTime").isNull();
}
...
}
[/code]

RichSet是我自己编造的一个名字。它是一个”rich“的set。其实就是附加了一些find，sort，sum之类的操作。

[code]
public interface RichSet<T> extends Set<T> {
Finder<RichSet<T>> find(String expression);
int sum(String expression);
}
[/code]

DefaultRichSet是这些附加操作的内存版本的实现。这个能解决问题么？还是不能，这时候getProcessingTasks的时候，richSet还是去遍历内部的_tasks，然后把结果过滤出来。而且，hibernate还拒绝接受这样set。为了让hibernate能够接受RichSet，我们需要这么写配置文件。


<hibernate-mapping default-access="field" package="net.sf.ferrum.example.domain">
    <class name="Employee">
        <tuplizer entity-mode="pojo" class="net.sf.ferrum.RichEntityTuplizer"/>
        <id name="id">
            <generator class="native"/>
        </id>
        <property name="name"/>
        <property name="salary"/>
        <many-to-one name="department"/>
        <set name="tasks" cascade="all" inverse="true" lazy="true">
            <key/>
            <one-to-many class="Task" />
        </set>
    </class>
</hibernate-mapping>

通过指定RichEntityTuplizer，我们可以控制Hibernate的动态增强过程。

[code]
public class RichEntityTuplizer extends PojoEntityTuplizer {
public RichEntityTuplizer(EntityMetamodel entityMetamodel, PersistentClass mappedEntity) {
super(entityMetamodel, mappedEntity);
}

protected Setter buildPropertySetter(final Property mappedProperty, PersistentClass mappedEntity) {
final Setter setter = super.buildPropertySetter(mappedProperty, mappedEntity);
if (!(mappedProperty.getValue() instanceof org.hibernate.mapping.Set)) {
return setter;
}
return new Setter() {
public void set(Object target, Object value, SessionFactoryImplementor factory) throws HibernateException {
Object wrappedValue = value;
if (value instanceof Set) {
HibernateRepository repository = new HibernateRepository();
repository.setSessionFactory(factory);
wrappedValue = new HibernateRichSet((Set) value, repository, getCriteria(mappedProperty, target));
}
setter.set(target, wrappedValue, factory);
}

public String getMethodName() {
return setter.getMethodName();
}

public Method getMethod() {
return setter.getMethod();
}
};
}
}
[/code]

这样，tasks就不再是DefaultRichSet了。Hibernate会尝试去增强为PersisentSet，但是被RichEntityTuplizer改写为增强HibernateRichSet了。这样就形成了HibernateRichSet -> PersisentSet -> DefaultRichSet -> HashSet 的包含关系。

当用户尝试在tasks上做find的时候，就不再是DefaultRichSet来做collection遍历了，而是HibernateRichSet去拼装一个DetachedCriteria。最后当用户在查询的结果上取size()或者取具体元素的时候，这个criteria被拿去求值。

通过使用RichSet，domain model具有了对自身进行查询的能力。更重要的是，这种能力的获得，不是通过把Hibernate session注入到domain model中。domain仍然是纯净的，没有依赖于数据库的东西。而且domain是可以脱离容器使用的。new Employee出来就可以直接使用，测试。区别只是经过repository增强的entity会使用sql，而transient的entity所有的查询都是通过遍历实现的。

没有了DAO之后，Domain Model是不是能够摆脱贫血的困扰呢？这个还需要观察。不过我认为至少是向前迈了一步了。