我现在也在面临着这么一个情况,以前总写些什么DAO, Service的东西,隐隐中感觉有些逻辑放在Domain Object里确实是一个最好的位置。可是我是用Hibernate的,将Domain Object Function与Persistent的Properties的Getter和Setter写在一起总感觉有些凌乱,各位老大是如何规划的呢?还有就是现在我们把DAO层和Service层都合到一个层里了,叫Process层。这样做是因为不少的所谓Service只是单纯的保存一些数据或者拿回一个数据集合(即单纯的数据处理),所以考虑到为了不要为了分层而分层,就把它们都合到一起了。这样做又隐隐有些不妥,请大家指点一下啊。
transaction script模式要求service实现所有商业逻辑,DAO实现持久化操作,model是“贫血”的。
domain model模式要求纯OO,即model做它应该做的所有事情,包括商业逻辑和持久化操作。
transaction script模式“太滥”,因为他不是面向对象;domain model模式太难,因为在model里无法实现持久化操作?
那么折中一下如何:
model只负责商业逻辑,不管持久化,商业逻辑方法所需db中的数据通过参数传递获得;
DAO还是负责持久化操作;
service不包含商业逻辑,它只负责为model的商业逻辑方法提供参数。
估计楼上的silvercat也这么想过吧?
因为写入Domain Model里的Domain Logic应该是这个Model个体特有的逻辑。
在很多复杂的情况下商务逻辑是在一个场景下进行的,即很多的Domain Model形成集合,相互协作,在这种情况下Service还是需要有逻辑。
至于Model只负责逻辑,不管持久化,我本来想这样,也可以避免耦合。
可是开发人员在写代码的时候会觉得别扭。
例如
public class Commitment {
...
public boolean reverse() {
this.set(...);
// 一大堆逻辑, 中间他还有可能想保存这个对象的一些子对象
// 最后他很想就这么保存了。可是我们告诉他别...
// this.save(); or PersistManager.save(this);
}
}
这样,可能感觉清晰,可是开发效率会变低。
至于持久化问题,既在Domain model中做又在service中做的方法是应该坚决反对的。要么全部在service中做,model需要的持久化信息通过参数传递;要么就全部做在Domain model里(不知道能不能实现,也许domain model design一书里有答案?)
http://www.theserverside.com/news/thread.tss?thread_id=38047
原文:http://jroller.com/page/habuma?entry=spring_2_0_vs_the
一个非贫血模型如下:
|