欢迎访问 夜阑小雨 我的学习碎片档案,这里记录了我的学习内容和工作中经验,希望给您带去帮助。

对领域模型实现的总结性观点

Java 夜阑小雨 860℃ 0评论

陶文发起的对领域模型的最新讨论:领域模型的与困境,在这个讨论当中,我的关注点是,在现在的技术水平下,我们如何把领域模型的理论和我们实际应用开发框架结合起来,总结出最佳实践:

第一、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。

转载请注明:夜阑小雨 » 对领域模型实现的总结性观点

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址