|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
TO Robbin
没有谁在讨论服务层的问题。 还是在讨论业务层，只不过你不要把我服务层的东西解释为你术语中的业务对象。 还有我实在是没明白你说的“不依赖于持久化的逻辑”到底是什么逻辑？能否给出解释？ |
| 返回顶楼 | |
|
发表时间：2005-03-23
type2怎么被折磨成这个样子:
引用 public class Forum { private List topics; private ForumDao forumDao; private TopicDao topicDao; public deletetopics(Rule rule) { ... 如果这个topics符合删除逻辑 this.topics.remove(xxx); ... forumDao.update(this); } } 我心中的是这样的: 引用 public class Forum { private List topics; private Session session; public deletetopics(Rule rule) { ... 如果这个topics符合删除逻辑 this.topics.remove(xxx); ... session.update(this); } } 注意 SESSION 本身维护的对象图阿，为什么要造这么个dao呢,dao就update和save来说 ForumDao TopicDao ; 有什么区别呢还不是做session.update();为什么要编两个名字？ 下面再说 retirve 方法，方法二更加有优势了利用对象之间的关系自由导航 order.getItems(0);.getProduct();.getProductAttachments();; 多爽阿 |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 TO Robbin
没有谁在讨论服务层的问题。 还是在讨论业务层，只不过你不要把我服务层的东西解释为你术语中的业务对象。 还有我实在是没明白你说的“不依赖于持久化的逻辑”到底是什么逻辑？能否给出解释？ 拿前面的例子来说，readonly举的那个发贴时间限制的的逻辑，这个逻辑实现是不依赖于持久化操作的，因此应该放在Forum类里面。 而后面我举的那个deleteTopics来说，这个逻辑的实现是必须依赖持久化操作的(forumDao)，我们必须把forumDao.update方法调用挪到外面去(放在Manager,Server或者其他的什么里面) |
| 返回顶楼 | |
|
发表时间：2005-03-23
frankensteinlin 写道 type2怎么被折磨成这个样子:
引用 public class Forum { private List topics; private ForumDao forumDao; private TopicDao topicDao; public deletetopics(Rule rule) { ... 如果这个topics符合删除逻辑 this.topics.remove(xxx); ... forumDao.update(this); } } 我心中的是这样的: 引用 public class Forum { private List topics; private Session session; public deletetopics(Rule rule) { ... 如果这个topics符合删除逻辑 this.topics.remove(xxx); ... session.update(this); } } 注意 SESSION 本身维护的对象图阿，为什么要造这么个dao呢,dao就update和save来说 ForumDao TopicDao ; 有什么区别呢还不是做session.update();为什么要编两个名字？ 下面再说 retirve 方法，方法二更加有优势了利用对象之间的关系自由导航 order.getItems(0);.getProduct();.getProductAttachments();; 多爽阿 老兄，建议你另外开贴讨论这个话题，你这个话题和这个讨论无关。你这个话题本质上就是 还需要不需要DAO层的话题，我的答案是需要，原因嘛，Rod Johnson的without EJB第10章专门论述过这个问题。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
8) ,正在对这个问题进行深入的实践和思考......
但也隐隐觉得，如果不把这两这观点放在一个具体的软件项目中比较，很难分清孰优孰劣？或者说这个问题本就没有答案，在复杂程度不同的项目中各有各的优势和劣势...... |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 拿前面的例子来说，readonly举的那个发贴时间限制的的逻辑，这个逻辑实现是不依赖于持久化操作的，因此应该放在Forum类里面。
而后面我举的那个deleteTopics来说，这个逻辑的实现是必须依赖持久化操作的(forumDao)，我们必须把forumDao.update方法调用挪到外面去(放在Manager,Server或者其他的什么里面) 这还需要区分吗？持久化也能叫做业务逻辑？ 如果不是，那么它根本不属于我们讨论的范畴。 我们讨论的标题是：“是否应该让实体类具备丰富的业务逻辑？”。 是业务逻辑啊，兄弟。 现在的结论不就是“应该让实体类具备丰富的业务逻辑” 了吗？ |
| 返回顶楼 | |
|
发表时间：2005-03-23
还是拿前面Readonly举的例子来说，readonly写的那个发贴时间限制的方法Topic的isAllowReply()
class Topic {
boolean isAllowReply() {
Calendar dueDate = Calendar.getInstance();
dueDate.setTime(lastUpdatedTime);
dueDate.add(Calendar.DATE, forum.timeToLive);
Date now = new Date();
return now.after(dueDate.getTime());
}
}
假设你是一个Web层的开发人员，你可以直接调用topic.isAllowReply()方法，你并不需要另外再写一个TopicService.isAllowReply(topic)。 再看Forum的deleteTopics这个方法，你不能够直接调用forum.deleteTopics(rule)，因为deleteTopics(rule)里面并没有做持久化动作，你必须调用ForumService.deleteTopics(forum,rule)来完成这个逻辑。 因为关系数据库毕竟是企业应用的核心，我们设计软件系统，毕竟不可能在完全不考虑技术实现的情况下去设计系统，数据持久化与否一定会对软件系统的架构产生极大的影响。以上面两个例子来对比，在这样两个例子中，底层的实体类其实都有非getter/setter的方法，但是从web程序员来说，一个因为需要持久化，所以必须通过Service层调用，一个因为不需要持久化，所以可以直接使用。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
引用 而后面我举的那个deleteTopics来说，这个逻辑的实现是必须依赖持久化操作的(forumDao)，我们必须把forumDao.update方法调用挪到外面去(放在Manager,Server或者其他的什么里面) 也就是说 我认为应该把update方法放在里面， 为什么？看看order.getTotalAccount();方法没有持久化的帮助如何计算？
Class Order{
getTotalAccount();{
List tempItems=getItems();;//需要持久化方法的调用
.................
while ..............
total+=item.price();;
..........
return total;
}
}
|
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 还是拿前面Readonly举的例子来说，readonly写的那个发贴时间限制的方法Topic的isAllowReply()
class Topic {
boolean isAllowReply() {
Calendar dueDate = Calendar.getInstance();
dueDate.setTime(lastUpdatedTime);
dueDate.add(Calendar.DATE, forum.timeToLive);
Date now = new Date();
return now.after(dueDate.getTime());
}
}
假设你是一个Web层的开发人员，你可以直接调用topic.isAllowReply()方法，你并不需要另外再写一个TopicService.isAllowReply(topic)。 再看Forum的deleteTopics这个方法，你不能够直接调用forum.deleteTopics(rule)，因为deleteTopics(rule)里面并没有做持久化动作，你必须调用ForumService.deleteTopics(forum,rule)来完成这个逻辑。 因为关系数据库毕竟是企业应用的核心，我们设计软件系统，毕竟不可能在完全不考虑技术实现的情况下去设计系统，数据持久化与否一定会对软件系统的架构产生极大的影响。以上面两个例子来对比，在这样两个例子中，底层的实体类其实都有非getter/setter的方法，但是从web程序员来说，一个因为需要持久化，所以必须通过Service层调用，一个因为不需要持久化，所以可以直接使用。 那说说update放到deleteTopics（rule）里边，有什么不好之处吧？和放在service里的区别就是原来是service依赖DAO接口，现在改成forum依赖DAO接口了。 如果大家都希望依赖关系越少越好的话，倒是可以根据这个来选择使用哪种方式，即object比service多那就让service去依赖dao，反之则让object去依赖dao。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 还是拿前面Readonly举的例子来说，readonly写的那个发贴时间限制的方法Topic的isAllowReply()
class Topic {
boolean isAllowReply() {
Calendar dueDate = Calendar.getInstance();
dueDate.setTime(lastUpdatedTime);
dueDate.add(Calendar.DATE, forum.timeToLive);
Date now = new Date();
return now.after(dueDate.getTime());
}
}
假设你是一个Web层的开发人员，你可以直接调用topic.isAllowReply()方法，你并不需要另外再写一个TopicService.isAllowReply(topic)。 再看Forum的deleteTopics这个方法，你不能够直接调用forum.deleteTopics(rule)，因为deleteTopics(rule)里面并没有做持久化动作，你必须调用ForumService.deleteTopics(forum,rule)来完成这个逻辑。 因为关系数据库毕竟是企业应用的核心，我们设计软件系统，毕竟不可能在完全不考虑技术实现的情况下去设计系统，数据持久化与否一定会对软件系统的架构产生极大的影响。以上面两个例子来对比，在这样两个例子中，底层的实体类其实都有非getter/setter的方法，但是从web程序员来说，一个因为需要持久化，所以必须通过Service层调用，一个因为不需要持久化，所以可以直接使用。 为什么要让WEB的程序员知道哪些方法需要通过Service层调用，哪些需要 通过实体类的方法调用呢？ Web程序员还需要关心持久化的概念？ 
就用你的例子，如果那天需求要求记录下被禁止回帖的情况。那不就死菜了？ 这时候再去添加个服务？ 举个实际的例子吧。 我做过的系统中曾经有一个是要记录登陆失败的日志的需求。 按照一般的要求，不需要记录，这样登陆失败就变成纯查询了。两者的区别还需要改变客户端调用的代码？ 再说让客户端开发人员必须要知道在一次服务中是否持久化，是不是有些怪异？ 如果你头脑中业务逻辑的概念，包含持久化。那么我认为你的观点是正确的。 因为按照我的理解业务逻辑是同持久化无关的。 所以排除你说的情况，实体类就该包含处理它自身数据的业务逻辑。 我想可以结贴了。over。 |
| 返回顶楼 | |
