|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-17
我一直有个疑惑，既然是用“贫血模型”那还要什么面向对象的语言。贫血模型和数据结构+函数有什么本质区别么？
|
| 返回顶楼 | |
|
发表时间：2011-04-17
最后修改：2011-04-17
ppgunjack 写道 错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
当业务变得复杂时，领域模型显出巨大的优势 这两句不矛盾吗？ 见过的电信标准亲一色都是数据service分离 ，各种各样的manager协调着各方数据 Unix管道的设计哲学是富血还是贫血，面向过程还是面向对象 多少人会把应该写成Add（a，b）的写成a.add(b) 以前写过电信设备inventory系统，得到的体会就是尽量把数据和处理分离，对象当成操作数，而不是操作的主体调用者，除非是它自己的吃喝拉撒，很多方法最早在域对象，后面都被移出去，做了很多无用功，最后的代码越来越接近标准接口的风格 在对象当中加方法太危险，用的时候很开心很方便，当方觉模型出问题的时候很揪心，尤其是被继承 扩散后 看到很多牛人的blog都是倾向c而不是c++来重新构建他们的系统，而且还不是因为性能 框架永远解决的是繁琐而简单的问题，最好让他们止于粘合层，能解决复杂问题的东西叫做产品 1.矛盾的那句话是别人说的，我并没有实践过DDD. 2.确实，我相信国内的大多数的javaee应用，都是贫血模型驱动的。我也做过不少电信行业的项目，基本上是你说的情况。但是吃喝拉撒放在一起的情况也很少见呀。 3.因为贫血模型不是那么OO，不好复用Domain逻辑，所以有人批呀。如： Martin Flowler批贫血的文章：AnemicDomainModel http://martinfowler.com/bliki/AnemicDomainModel.html 4.而且现在确实也有人在实践DDD，成效怎样并不知道。能看到有人现身说法就好了。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
lzyzizi 写道 我一直有个疑惑，既然是用“贫血模型”那还要什么面向对象的语言。贫血模型和数据结构+函数有什么本质区别么？
虽然贫血模型把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则，但OO还有很多其它的特性和原则，还有设计模式等。所以用Java这种80%的OO语言，也没什么大不了吧。更何况还有j2ee without ebj的盛行，和hibernate这些o/r mapping的框架，有pojo,在国内外java盛行也正常了。虽然现在java有很多人垢病，但还是我们赖以生存的谋手生段。 
|
| 返回顶楼 | |
|
发表时间：2011-04-17
无语中，已经变成一场否定OO的讨论了
|
| 返回顶楼 | |
|
发表时间：2011-04-17
yangyi 写道 无语中，已经变成一场否定OO的讨论了
为什么有这样的感想？虽然我大多数时间都在用贫血的东西。但DDD，应该是更OO才对吧？ |
| 返回顶楼 | |
|
发表时间：2011-04-17
yangyi 写道 除非能够抛弃关系型数据库，否则对此不抱乐观。ORM从某种程度上说，并没有取得成功，OO的视角是流转的数据，而DB的视角是数据的流转，这种矛盾从架构上是不可调和的。除非能够在业务系统中淡化数据库的角色（隔离它），或者干脆用新的持久化方法（取代它）。原因还是和上面说的一样，数据库的访问方式决定了它的侵入性。
ORM不就是隔离DB的手段嘛。ORM本身就是来调合这些东西的，所以有hibernate的盛行。ORM至少从多年应用来看，还是算成功的。我想现在，甚至几年前的DDD实践者应该都用的是关系数据库吧。面向OO对象的DB，要盛行应该不会是10年之内的事。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则
不能一概而论，这要考虑A contact B这个很有广泛性形式的业务转化成A、B、contact谁主导的问题，没有绝对不变的答案 Db.save(A),A.save(DB),save(DB,A), 我觉得其实第三种是侵入最小，最容易复用和重构的，尤其是在对三者职能划分还没理解透的情况下 很多时候其实很难判断一个方法应该在域模型还是放到专属service对象 是否复用我觉得和是不是把方法放进class其实没关系，而是是否遵循了最小依赖设计的原则 RDBMS的范式设计其实就是实体表--关系表---实体表这样的一种设计体现，关系的抽出让实体更加纯粹，OO与DB最难调和的恰恰是继承多态这些关系 OO更适合处理树形继承关系，问题在于对象和对象远不止这种关系，所以需要第三方的manager去处理那些继承和多态不好覆盖的逻辑 |
| 返回顶楼 | |
|
发表时间：2011-04-17
ppgunjack 写道 把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则
不能一概而论，这要考虑A contact B这个很有广泛性形式的业务转化成A、B、contact谁主导的问题，没有绝对不变的答案 Db.save(A),A.save(DB),save(DB,A), 我觉得其实第三种是侵入最小，最容易复用和重构的，尤其是在对三者职能划分还没理解透的情况下 很多时候其实很难判断一个方法应该在域模型还是放到专属service对象 没怎么明白你上面的逻辑。db是什么东西？你是不是指关联对象？比如计算费用 那么我们Account.bill(OtherDomain)行不行呢？bill内部有处理逻辑呀。 ppgunjack 写道 OO更适合处理树形继承关系，问题在于对象和对象远不止这种关系，所以需要第三方的manager去处理那些继承和多态不好覆盖的逻辑 我觉得DDD+设计模式应该可以处理好这样的东西。 |
| 返回顶楼 | |
|
发表时间：2011-04-17
db就理解成B就好了
|
| 返回顶楼 | |
|
发表时间：2011-04-17
最后修改：2011-04-17
对于你上面所说的这种问题。应该指的是方法逻辑划分在哪个domain下面更合适。这就要搞domain model的人既要很懂领域知识，又要有丰富的设计经验才行，能事先看到以后的一些问题，并避免那样的问题发生。所以我也觉得ddd,一旦设计不好，就会带出很多问题，包括domain间逻辑的反复变化。
|
| 返回顶楼 | |
