|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
Archie 写道 哦，那双向依赖有什么不好之处吗？
没什么不好。不过如果两个类型（包括接口）是相互依赖的关系的话，你就需要 把它们放到同一包中。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 Archie 写道 哦，那双向依赖有什么不好之处吗？
没什么不好。不过如果两个类型（包括接口）是相互依赖的关系的话，你就需要 把它们放到同一包中。 那不是要把DomainObjects放到DAO的包里了？ 那业务逻辑的Package不就是依赖 DAO的package了？？ |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 那不是要把DomainObjects放到DAO的包里了？
那业务逻辑的Package不就是依赖 DAO的package了？？ DAO的接口同DomainObject在同一个包中, DAO的实现在另外一个包中，明白吗？ 再不明白，就去阅读MartinFowler的《Patterns of Enterprise Application Architecture 》第18章Separated Interface。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 Archie 写道 那不是要把DomainObjects放到DAO的包里了？
那业务逻辑的Package不就是依赖 DAO的package了？？ DAO的接口同DomainObject在同一个包中, DAO的实现在另外一个包中，明白吗？ 再不明白，就去阅读MartinFowler的《Patterns of Enterprise Application Architecture 》第18章Separated Interface。
public class CustomerFinderImpl implements ICustomerFinder
{
Customer findByCustomerCode(String customerCode);
{
Query query=this.pm.newQuery(Customer.class);;
query.setFilter("customerCode=="+customerCode);;
query.setUnique(true);;
return (Customer);query.execute();
}
}
这样CustomerFinderImpl 不算是依赖Customer是吧。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 这样CustomerFinderImpl 不算是依赖Customer是吧。
算依赖Customer，不好意思，要走了。 总结一下 DomainObject需要依赖DAO的接口，反之亦然。 DAO的实现依赖DomainObject和DAO的接口。 去看书，什么都明白了。  拜拜。
|
| 返回顶楼 | |
|
发表时间：2005-03-24
robbin 写道 引用 我现在的做法就是把需要多个domain object互相协作的方法放到Services里，也好做事务和权限控制。这种TransactiionScript免不了的。有点像多态，难道有了多态就不需要if语句了？只不过if语句只会出现一次，以后就都是多态了。
如果TransactionScript无法避免的话，我宁愿放弃Martin大叔的Domain Object模型，还是用我自己的那种Domain Object模型。 因为Domain Object之间的交互是无可避免的，万一某个domain object自己的业务逻辑，经过需求变更之后，现在需要其他的domain object参与协作了，那么按照你的说法，我就必须把这个业务逻辑方法从domain object挪到TransactionScript去，嘿嘿，同样无法避免我提到的两个问题，一点都没有省。 所以Martin Fowler的Domain Object也就是看起来挺好而已。 有一点觉得奇怪: 为什么domain object 相互协作就一定要移动到service呢, domain object 之间本来就是相互依赖的。还是以Order 为例子，Order 要计算他的总价，但是它可能还与Buyer对象相关，对不同的buyer有不同的 discount，(例子不再做引申，不讨论例子本身的合理性,全部语义在此)：
Class Order{
public countPrice{
Items item =getItems();;
while (....);{
item.getPrice();*getBuyer();.getDiscount();;
}
}
}
如果用service+dao+*类型1*的对象该如何写？可能会非常复杂哦 |
| 返回顶楼 | |
|
发表时间：2005-03-24
路过，感觉这帖子口水话太多，大家都想清楚了一次说完不好吗？
|
| 返回顶楼 | |
|
发表时间：2005-03-24
DDOS的设计就是第二种的设计，用起来超级不爽，别的就不多说了。随便专家怎么说，那样用着舒服用那样，还是继续走纯po路线。
|
| 返回顶楼 | |
|
发表时间：2005-03-24
frankensteinlin 写道 robbin 写道 引用 我现在的做法就是把需要多个domain object互相协作的方法放到Services里，也好做事务和权限控制。这种TransactiionScript免不了的。有点像多态，难道有了多态就不需要if语句了？只不过if语句只会出现一次，以后就都是多态了。
如果TransactionScript无法避免的话，我宁愿放弃Martin大叔的Domain Object模型，还是用我自己的那种Domain Object模型。 因为Domain Object之间的交互是无可避免的，万一某个domain object自己的业务逻辑，经过需求变更之后，现在需要其他的domain object参与协作了，那么按照你的说法，我就必须把这个业务逻辑方法从domain object挪到TransactionScript去，嘿嘿，同样无法避免我提到的两个问题，一点都没有省。 所以Martin Fowler的Domain Object也就是看起来挺好而已。 有一点觉得奇怪: 为什么domain object 相互协作就一定要移动到service呢, domain object 之间本来就是相互依赖的。还是以Order 为例子，Order 要计算他的总价，但是它可能还与Buyer对象相关，对不同的buyer有不同的 discount，(例子不再做引申，不讨论例子本身的合理性,全部语义在此)：
Class Order{
public countPrice{
Items item =getItems();;
while (....);{
item.getPrice();*getBuyer();.getDiscount();;
}
}
}
如果用service+dao+*类型1*的对象该如何写？可能会非常复杂哦 这个是血小板比较多的Domain Object，而且只是涉及到Domain之间的交互，不会和什么数据库打交道的，我们有时候也会用这种小技巧，毕竟原则是死的，人是活的。不过还是还是写为getCountPrice()比较好吧，这样上层调用起来统一一些。 |
| 返回顶楼 | |
|
发表时间：2005-03-24
引用 万一某个domain object自己的业务逻辑，经过需求变更之后，现在需要其他的domain object参与协作了，那么按照你的说法，我就必须把这个业务逻辑方法从domain object挪到TransactionScript去
不是把domain object中的逻辑挪到Services中去。一般来说domain object不需要改变，但是可能需要增加一个新的Services方法来协调新参与的协作。这种需求往往也是应用逻辑而不是业务逻辑。 引用 为什么domain object 相互协作就一定要移动到service呢
因为协调各个domain object 这是一个控制类的责任，不属于某个domain object 的责任。 引用 item.getPrice()*getBuyer().getDiscount();
这是非常糟糕，也是非常常见的Bad Smell！它有个名字叫“train wreck”。请注意不要与陌生人讲话原则。 |
| 返回顶楼 | |
