陶文发起的对领域模型的最新讨论:领域模型的与困境,在这个讨论当中,我的关注点是,在现在的技术水平下,我们如何把领域模型的理论和我们实际应用开发框架结合起来,总结出最佳实践:
第一、DAO层和TransactionScript层是邪恶的!
我们在2004年一直跨度到2007年讨论来讨论去,其实都有一个隐含的前提条件:你的领域模型终究无法脱离对DAO层的依赖,以及需要 TransactionScript层的包裹。而这样一来,领域模型的通用性、可移植性、业务逻辑的表达能力基本全部丧失,沦为框架限制下的奴隶。
而我们看看现在Java领域的技术进步,JPA已经普及,EJB3的隐含事务管理,甚至连Spring也可以简化成@Transactional,现在已经是我们可以去掉DAO和TransactionScript的时代了。
第二、Seam在消除了DAO层和TransactionScript以后,领域模型的感觉已经呼之欲出
这个不用多说,大家自己去看Seam文档好了。我唯一想强调的是entity bean和business bean分开有没有必要性,我的看法是有必要!这还是和Java本身语言的限制有关系:
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
2、business bean的很多业务逻辑方法需要容器环境,不像Rails的model可以直接mixin进来
3、Java做为目前最主流的工业语言,开发团队都是大规模编码协作的,你都放在一个class里面,团队协作会遇到很大的麻烦(事实上RoR现在也有这样的问题,但是RoR开发效率高,往往不需要那么大规模的开发团队)
3、领域模型不同类别的业务逻辑可以很容易的分到几个不同的business bean里面,这样对团队协作的好处很大。
第三、不考虑框架限制,All-in-One的领域模型好不好?
比方说RoR的model就是All-in-One的,但是一旦出现可以抽象出来,比较通用的业务逻辑,我们还是会把这些逻辑抽出来,单独实现,然后再mixin回去。所以没有必要All-in-One,根据你的实际需要来决定放在一个class里面,还是拆开成几个class。
所以最终我对这个问题的总结就是:
一、只要技术框架能够实现,尽量使用领域模型
二、无论Java还是Ruby,必须消灭DAO和TransactionScript
三、领域模型不必All-in-One,Java可以分割为 1个entity bean和几个business bean,而Ruby可以分割为1个model和几个mixin的module。
转载请注明:夜阑小雨 » 对领域模型实现的总结性观点