|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
我现在的疑问是事务能否完全依赖容器或者AOP框架来管理。还有就是ORM框架能否做到让Object脱离持久层又能无缝的回到持久层,并脱离且仅脱离一次。
抽时间做个例子看看吧。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 不过对于把所有的逻辑(包括持久化服务)都塞到domain object里面我也有疑问。因为我们知道有一些逻辑他一定需要多个domain object互相协作完成的，那么这个时候这个逻辑究竟应该放在哪个domain object里面好呢？还是需要再弄一个TransactiionScript出来？ 而如何再弄一些TransactionScript出来的话，岂不是又会出现我前面说的问题吗？ Web程序员究竟该如何选择，调用TransactionScript类，还是调用domain object类？
这样考虑下来的结果，好像只有getter/setter的纯数据类反而最好？因为纯数据类就只映射数据库字段，数据库字段是不会轻易变动的，所以这样的实体映射类也最稳定。 呵呵，脑袋转的曼快嘛。 解决方法是DomainObject通过UnitOfWork注册，事务提交通过Service层来完成。Web程序员只通过服务同后台交互。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 Archie 写道 to partech: 你还没给我解释那个图呢。
好吧。不要把圆柱体的东西都理解为数据库好吗？ MartinFowler的意思是DomainObject也需要持久化啊。 持久化也好，那不就是DomainObject依赖持久化接口吗？ |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 不过对于把所有的逻辑(包括持久化服务)都塞到domain object里面我也有疑问。因为我们知道有一些逻辑他一定需要多个domain object互相协作完成的，那么这个时候这个逻辑究竟应该放在哪个domain object里面好呢？还是需要再弄一个TransactiionScript出来？ 而如何再弄一些TransactionScript出来的话，岂不是又会出现我前面说的问题吗？ Web程序员究竟该如何选择，调用TransactionScript类，还是调用domain object类？
这样考虑下来的结果，好像只有getter/setter的纯数据类反而最好？因为纯数据类就只映射数据库字段，数据库字段是不会轻易变动的，所以这样的实体映射类也最稳定。 我现在的做法就是把需要多个domain object互相协作的方法放到Services里，也好做事务和权限控制。这种TransactiionScript免不了的。有点像多态，难道有了多态就不需要if语句了？只不过if语句只会出现一次，以后就都是多态了。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 partech 写道 Archie 写道 to partech: 你还没给我解释那个图呢。
好吧。不要把圆柱体的东西都理解为数据库好吗？ MartinFowler的意思是DomainObject也需要持久化啊。 持久化也好，那不就是DomainObject依赖持久化接口吗？ 没错阿，DomainObject是要依赖持久化的接口阿。 所以是双向依赖 DomainObject<----------->DAO接口。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 Archie 写道 partech 写道 Archie 写道 to partech: 你还没给我解释那个图呢。
好吧。不要把圆柱体的东西都理解为数据库好吗？ MartinFowler的意思是DomainObject也需要持久化啊。 持久化也好，那不就是DomainObject依赖持久化接口吗？ 没错阿，DomainObject是要依赖持久化的接口阿。 所以是双向依赖 DomainObject<----------->DAO接口。 那我还没找到必须双向依赖的情况呢。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 那我还没找到必须双向依赖的情况呢。
看看这个接口： public interface ICustomerFinder
{
Customer findByCustomerCode(String customerCode);;
}
|
| 返回顶楼 | |
|
发表时间：2005-03-23
还有一个问题.DomainObject从哪里来?
前面的讨论中,似乎看到一个Repository方案: Forum f = forumRepository.findById(forumId);; 这个Repository是个什么对象? 它既然用来获取DomainObject的,那么,也就是说,它和DAO干(部分)相同的工作,它与之前被"隐藏"到DomainObject后面的那些DAO有什么区别呢? 另外一种方案是DomainObject获取它自己. 那么我们也许得到一些代码类似这样: // 比如这样,非static的 Forum f = (new Forum(););.findById(forumId);; // 或者这样,static的 Forum f = Forum.findById(forumId);; 这...,好么? |
| 返回顶楼 | |
|
发表时间：2005-03-23
引用 我现在的做法就是把需要多个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也就是看起来挺好而已。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
jackyz 写道 还有一个问题.DomainObject从哪里来?
前面的讨论中,似乎看到一个Repository方案: Forum f = forumRepository.findById(forumId);; 这个Repository是个什么对象? 它既然用来获取DomainObject的,那么,也就是说,它和DAO干(部分)相同的工作,它与之前被"隐藏"到DomainObject后面的那些DAO有什么区别呢? 另外一种方案是DomainObject获取它自己. 那么我们也许得到一些代码类似这样: // 比如这样,非static的 Forum f = (new Forum(););.findById(forumId);; // 或者这样,static的 Forum f = Forum.findById(forumId);; 这...,好么? 引入Repository只是为了减少代码，因为DAO接口是没法直接使用得的，通过 Repository将它封装了。 呵呵，你下面的这段代码比较搞笑。“什么叫自己获取自己啊” 哈哈 将查找方法放入类的静态方法似乎不合适的，这样在需要新的查询方法时，就不得不改类了。这不符合单一职责原则。 |
| 返回顶楼 | |
