|
锁定老帖子 主题：要领域模型干嘛？
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-27
最后修改：2008-11-27
充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？
ps：充血还是贫血对单元测试有影响吗？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
fnet 写道 我觉得根据业务需求吧
过于复杂的需求还是用贫血 一般需求用充血 说实话我是喜欢用充血，而这方面ROR里的model做的最好。 充血的model的确更有意义，并且更方便。 你说要领域模型干嘛？可以去比较一下国内的一些面向过程的PHP的CMS，看看如果没有领域模型，是什么样的情况。 不要藏着掖着嘛，没有领域模型，情况到底会怎么样？“过于复杂的需求还是用贫血”，那是为什么呢？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
daquan198163 写道 充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？
嗯，是啊，为什么呢？我也想知道。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
什么是充血模型？我很想知道。从大家以前的讨论来看，我感觉充血模型就是将持久化逻辑放在实体(Entity)中。如果连这个都不清楚，讨论就没有必要。
要讨论Domain，我觉得大家都应该看看Eric Evans的《Domain Driven Design》。Domain不仅仅只有Entity，还有Value Object，Service。将很多东西写User类就是领域模型吗？完全错误！领域模型要求将职责分配到各自的对象（Entity,Value Object和Service)。另外强烈推荐《POJO in Action》这本书，它从实战的角度清晰的讲述了该如何进行领域设计。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
在反对领域模型之前，请千万弄清楚领域为何物。
|
| 返回顶楼 | |
|
发表时间：2008-11-27
lifethinker 写道 什么是充血模型？我很想知道。从大家以前的讨论来看，我感觉充血模型就是将持久化逻辑放在实体(Entity)中。如果连这个都不清楚，讨论就没有必要。
要讨论Domain，我觉得大家都应该看看Eric Evans的《Domain Driven Design》。Domain不仅仅只有Entity，还有Value Object，Service。将很多东西写User类就是领域模型吗？完全错误！领域模型要求将职责分配到各自的对象（Entity,Value Object和Service)。另外强烈推荐《POJO in Action》这本书，它从实战的角度清晰的讲述了该如何进行领域设计。 
说得好，职责是关键。领域模型设计最后结果应该是一个网状的类结构，来共同表达领域知识 |
| 返回顶楼 | |
|
发表时间：2008-11-27
我认为领域模型是固定的，如果你把那些可以变动的逻辑也认为是领域模型里面的逻辑，我觉得是不对的
完善的领域模型里面的逻辑是固定不变的，最起码接口是不变的 那些经常变动的需求，并不能算是'领域'模型里面的一部分 |
| 返回顶楼 | |
|
发表时间：2008-11-27
bloodrate 写道 Domain带来的最大一个好处我认为就是容易测试。
Junit,Junit从一开始就有一个很矛盾的地方，那就是：在没有自动测试框架的时候，单元测试原本是白盒测试，因为代码的任何角落都有可能出现问题，这些琐碎问题体现的形式不一，没法抽象出一种统一的模式来测试，Junit出现后Junit仿佛是在用黑盒测试来实现单元测试，一味的asert验证方法的结果，对于那些本该由单元测试中测试的程序代码片断无从下手（现在为止很多人只测试代码覆盖率，比如程序中有一个循环，按照输入条件这个循环应该执行10次，你只能测试执行到了这个循环，至于这个循环是否真的执行了10次无从下手）。所以我认为自动化测试框架所能测出的应该单元测试期测试出现的问题非常有限。 使用mock对象， 还是可以检测循环是不是被执行了10次。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
ThinkingInAll 写道 我认为领域模型是固定的，如果你把那些可以变动的逻辑也认为是领域模型里面的逻辑，我觉得是不对的
完善的领域模型里面的逻辑是固定不变的，最起码接口是不变的 那些经常变动的需求，并不能算是'领域'模型里面的一部分 你怎么区分什么是固定的逻辑，什么是变动的逻辑呢？需求不是领域的一部分，那什么是领域的一部分？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
lifethinker 写道 什么是充血模型？我很想知道。从大家以前的讨论来看，我感觉充血模型就是将持久化逻辑放在实体(Entity)中。如果连这个都不清楚，讨论就没有必要。
要讨论Domain，我觉得大家都应该看看Eric Evans的《Domain Driven Design》。Domain不仅仅只有Entity，还有Value Object，Service。将很多东西写User类就是领域模型吗？完全错误！领域模型要求将职责分配到各自的对象（Entity,Value Object和Service)。另外强烈推荐《POJO in Action》这本书，它从实战的角度清晰的讲述了该如何进行领域设计。 持久化逻辑就是一切了吗？还有，什么是持久化逻辑呢，存储和查询是一回事吗？ |
| 返回顶楼 | |
