|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
robbin 写道 既然你也建议应该把forumDAO.update放到一个xxxManager里面去做，那么实际上我们的观点是一致的，你实际上主张的也是我主张的第一种模型，你想明白没有？ 不太一样，我只是吧update这种持久化的操作放到XXManager里边去了。但是delete的逻辑还是在Forum里边。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Lee 写道 引用 把forumDAO.update放到一个xxxManager里面去
这个xxxManager是工具类吗？ 应该不算是工具类，是个业务类，比如叫做论坛管理器。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 robbin 写道 Archie 写道 首先明确：第二种不是robbin画的那样，而是这样的：
你这个图里面的object，string都是些什么东西，看不懂，给解释解释。 就是DAO不依赖与Domain Objects DAO.update(Object obj); DAO.save(Object obj); DAO.delete(Class clazz,Object obj); 那你这些obj是什么呢？还不是只有getter/setter的数据类？ 这样的话，更加是贫血的了。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 Archie 写道 robbin 写道 Archie 写道 首先明确：第二种不是robbin画的那样，而是这样的：
你这个图里面的object，string都是些什么东西，看不懂，给解释解释。 就是DAO不依赖与Domain Objects DAO.update(Object obj); DAO.save(Object obj); DAO.delete(Class clazz,Object obj); 那你这些obj是什么呢？还不是只有getter/setter的数据类？ 这样的话，更加是贫血的了。 这不叫依赖Domain Object吧。DAO只是依赖Object而已。而且这些Object是具有业务逻辑的，只不过在DAO里不会使用到，在业务层才会被用到。DAO里边不会有类型转换的。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
to Archie: 我觉得你的模型并不是我上面讲的第二种模型，也不是Marin Fowler讲的domain object。或者我们可以叫它第三种模型，建议你给出一个该模型完整的案例代码，否则大家的讨论仍然是各讲各的，不是再说一回事。
而且你的模型我感觉有很多问题，例如domain object的状态和你所谓的object，string这些东西是什么关系等等。所以还是写出来代码再讨论吧。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
CRUD是业务逻辑吗？我觉得不是。
CRUD应该在业务逻辑中吗？我觉得不应该。 CRUD应该出现在DM中吗？我也觉得不应该。 以下的观点，纯粹是自己的思考，没有实践，也没有大师的理论，希望能够得到大家的指正。 public class Forum {
private List topics;
private ForumDao forumDao;
private TopicDao topicDao;
public deletetopics(Rule rule); {
List deletetopics = topicDao.findTopics(forum, rule);;
forumDao.deletetopics(deletetopics );;
}
}
public class Forum {
private List topics;
private ForumDao forumDao;
private TopicDao topicDao;
public deletetopics(Rule rule); {
...
如果这个topics符合删除逻辑
this.topics.remove(xxx);;
...
forumDao.update(this);;
}
}
Interface ForumDAO
{
update(Object obj);;
}
上面的两段代码，并没有本质上的区别。不过可以看出第二段代码的一些思路，对其进一步改进，可以得到如下代码。 public class ForumTransactionScript {
private ForumDAO forumDao;
public deletetopics(Forum forum, Rule rule); {
forum.deletetopics(rule);;
forumDao.update(forum);;
}
}
public class Forum {
private List topics;
public deletetopics(Rule rule); {
...
如果这个topics符合删除逻辑
this.topics.remove(xxx);; // 这个才是业务逻辑。对数据库的读写不是业务逻辑，而是系统架构的I/O操作。
}
}
Interface ForumDAO
{
update(Object obj);;
}
上面这段代码中， Forum 是一个纯粹的DomainModel ， 所以说它纯粹，是因为他没有涉及到I/O操作。 ForumTransactionScript 这个新加的类，表名了一种业务上的一种事务操作。为什么是 Transaction Script ，对于业务建模采用 Domain Model 是适合的，但对于具体某一事务性业务，用Transaction Script是最合适的。也就是说即使我们采用DomainModel，Transaction Script也是不可避免的，只不过Transaction Script表示一种粗粒度的业务过程调用。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 to Archie: 我觉得你的模型并不是我上面讲的第二种模型，也不是Marin Fowler讲的domain object。或者我们可以叫它第三种模型，建议你给出一个该模型完整的案例代码，否则大家的讨论仍然是各讲各的，不是再说一回事。
很抱歉为了直观起见，引入了Martin Fowler网站上的一张图。 我想我和这种方式的区别可能就是上个forumDAO.update()放在forum里边还是单独拿出来搞个XXXManager。也就是什么时候持久化，由对象自己决定还是由他的管理者来决定。 如果事务控制使用容器控制，或者使用类似spring的框架，现在觉得倒是由对象自己决定持久化的时机比较好(当然是委托给DAO去做)。这样的化管理者的逻辑更清楚,我就是让你删掉符合规则的帖子！ 业务逻辑不管对象保存在哪里，也不关心数据库是什么东西，在管理者的眼里没有数据库。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
to 七彩狼:
很高兴看到你这个帖子里面阐述的观点，我想说的是，其实经过你修改后的这段代码就是我一直主张的第一种模型。在这里Forum这个实体类他是可以也应该带有逻辑的，但是他带有的逻辑应该是有状态的，不依赖持久化的逻辑。那些无状态的，依赖持久化的逻辑则分离到业务逻辑对象中去（就是你例子中的ForumTransactionScript，专业一点的命名就是xxxManager） |
| 返回顶楼 | |
|
发表时间：2005-03-23
动物园的猪 写道 一个业务系统而言，什么是最重要的，就是业务，我们在各种书中看到的都是业务的建模，业务的建模和技术无关的，我们使用OOA的方式，分析业务的概念模型，进行所谓的领域模型分析，这些都是业务范畴的，和技术无关。
然后有了领域模型后，领域模型是一个静态的视图，他只是表明实体，属性和关联，而领域模型的行为，往往要到向具体技术映射的时候，在详细的考虑， 这就到了设计的阶段，设计阶段，我们说白了是在干什么？是在使用java语言进行领域建模的深化，POJO也好，ebj也好，都是手段，只是想把我们抽象出来的 领域模型技术化。 我们明确这个过程后，我们就明白多了，业务建模是最先要做的东西，到了后期，我们才突然想起，噢！我们需要进行业务的数据的存储，然后我们想到了o-r映射。 所以，技术实现的领域模型，应该是一个相对独立的东西，他的目标是表达业务的领域模型。 有了这个领域模型后，我们考虑序列化了，我的想法呢，就这样。 持久层需要有专门的PO(persistence object),我把我的领域模型，通过一层(叫DataMapping)，把她导成PO的关系，在DAO中，最终完成数据的存取。 也就是说，领域模型不应该意识到什么叫做持久化，而持久化层，也不知道领域模型，双方靠一个映射层(DataMapping)，完成转化。 领域模型并没有被直接序列化，也不应该直接被序列化，而是经过了一个转化。 当然，这只是一个思路，这个思路强调的是关注业务，然后是技术。 当然，这个思路也是看书看来的，并没有在复杂的业务系统中实践过，说出来供大家参考。 为什么一定要多一个映射层呢? 为什么要有一个只代表底层数据的PO呢?既然领域模型的实现需要到POJO的属性数据,为什么一定要把本属于领域模型的数据分离到POJO上呢?中间还要加入一层 Mapping? 为什么不能赋予 领域模型可持久化的行为呢? 虽然三层模型那么流行,但是并不表明只要分层就是好的! 在设计具体的领域模型实现时,我们为什么不能赋予他可持久化的行为呢? |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 robbin 写道 to Archie: 我觉得你的模型并不是我上面讲的第二种模型，也不是Marin Fowler讲的domain object。或者我们可以叫它第三种模型，建议你给出一个该模型完整的案例代码，否则大家的讨论仍然是各讲各的，不是再说一回事。
很抱歉为了直观起见，引入了Martin Fowler网站上的一张图。 我想我和这种方式的区别可能就是上个forumDAO.update()放在forum里边还是单独拿出来搞个XXXManager。也就是什么时候持久化，由对象自己决定还是由他的管理者来决定。 如果事务控制使用容器控制，或者使用类似spring的框架，现在觉得倒是由对象自己决定持久化的时机比较好(当然是委托给DAO去做)。这样的化管理者的逻辑更清楚,我就是让你删掉符合规则的帖子！ 业务逻辑不管对象保存在哪里，也不关心数据库是什么东西，在管理者的眼里没有数据库。 至于持久化方法是否要放在domain object中这已经不需要再讨论了，肯定是应该剥离出去的，前面帖子中已经非常详细讨论过这个问题了，如果再要讨论这个问题，还是另开帖子讨论，这里不要跑题了。 另外我还是看不懂你那个图要表达什么，还是给代码吧。 |
| 返回顶楼 | |
