|
锁定老帖子 主题：也谈领域对象的数据与动作分离
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-19
ray_linn 写道 是不是充血的鸡翅就能比贫血的鸡翅卖得更好价钱？
不能的话没事干嘛折腾自己，统统贫血，不是简单又美味吗？ +1 |
| 返回顶楼 | |
|
发表时间：2008-09-20
当前遇到的问题是ibatis好像不太容易执行动态生成SQL，各位有没有什么经验
因为sql中where字句是通过具体的运行时逻辑产生的 |
| 返回顶楼 | |
|
发表时间：2008-09-20
答：因为企业级的Web+业务逻辑+数据库应用不适合OO。
为什么这样说呢？一个数据模型是对一套业务的完整抽象，因此数据库是业务系统的骨干。不幸的是，当前流行的数据库是关系型数据库而非OO数据库，这就造成了整个架构上的不匹配。所以从整个系统的架构上来说，并非OO，包括PO和DAO在内的方法，元素都是借用了一个OO语言描述一个非OO的语意。因此不应强制一定要OO，可以在实现具体业务时借用OO，但整个架构上并非如此。 ?? |
| 返回顶楼 | |
|
发表时间：2009-01-24
最后修改：2009-01-24
如果把所有的基础架构代码或者业务代码放置到领域模型类中，这些类就变得“肥胖不堪”，难于使用和维护。但是，如果我们把它放在领域模型类之外，我们又使其变为“贫血的”领域模型，不能充分利用面向对象的潜力。
实现充血模型的一个比较好的实践是使用领域对象代理子类，不知楼主的manager是不是可以看做或当做DomainObject的代理子类（我不知道具体代码不敢确定），如果可以的话，那么manager和DomainObject可以作为一个整体，这样就是个很优雅的DDD实践，貌似贫血但其实是充血的 |
| 返回顶楼 | |
|
发表时间：2009-01-29
wq163 写道 如果把所有的基础架构代码或者业务代码放置到领域模型类中，这些类就变得“肥胖不堪”，难于使用和维护。但是，如果我们把它放在领域模型类之外，我们又使其变为“贫血的”领域模型，不能充分利用面向对象的潜力。
实现充血模型的一个比较好的实践是使用领域对象代理子类，不知楼主的manager是不是可以看做或当做DomainObject的代理子类（我不知道具体代码不敢确定），如果可以的话，那么manager和DomainObject可以作为一个整体，这样就是个很优雅的DDD实践，貌似贫血但其实是充血的 期待给出一段代码来看看 
|
| 返回顶楼 | |
|
发表时间：2009-02-09
本人理解领域模型应该是需求分析的范畴，是系统分析和设计的输入，系统分析根据领域模型建立分析模型，而系统的设计与使用的应用框架相关，如果单说领域模型的话，不应该有贫血只说。
|
| 返回顶楼 | |
|
发表时间：2009-03-02
目前就是这样做的，不过看了lz的引用，又有了点新的想法，在实际业务中，domain ojbect是不应该存在update_time,remark等与业务无关的属性，这些属性应该是属于po，只是orm的存在我们可以把pojo当作po来用，导致在pojo中存在所有数据库中的字段，而不分该字段是否是domain相关
|
| 返回顶楼 | |
