|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
robbin 写道 Archie 写道 看看这个例子：
老实说，我觉得你们对第一种模型（即所谓贫血模型）理解有误，你们认为实体类就是只有getter/setter方法的数据类，这是误解。就你画出来的这个UML类图来说，即使在第一种模型中，这些方法也是必须放在实体类内部的。 我们目前项目中的做法,在实体(或许不能称之为实体，因为没有持久化，而仅仅只能称之为VO或者是DTO)中，仅仅只有getter/setter方法。 我们项目大体的架构是这样的，action->business logic->transaction->dao->db,还有form和vo，其中form对象中包括vo(方便传递数据)，在action层中调用form，在后面的三层中都是通过传递vo作为参数。 在这种架构中，我们很少看到拥有除getter/setter方法之外的实体对象，我也一直对这种架构存在着怀疑态度。 请问robbin，你所说的那种实体对象的具体使用场景是怎样？能够举个例子。 谢谢！ 
|
| 返回顶楼 | |
|
发表时间：2005-03-23
先表个态：我也是第二种模型的支持者！
引用 我会建模为一套继承体系结构的实体类，和一个业务逻辑处理类
这样很可能你会根据实体类的继承体系，配套实现一个业务逻辑处理类的继承体系。于是就出现了平行的继承体系，这是一种Bad Smell。坏处不用说了吧。 至于单一职责原则，这种贫血的实体类实际上是没有承担任何职责的，充其量就是个数据结构表示。根据我的经验，除了“参数类”外，那些只有属性没有方法的类往往都是有问题的。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
to Readonly:
你举的那几个例子实际都是第一种模型例子。你并没有举出第二种模型的例子。真正第二种模型的例子是这样的： 例如根据论坛删贴规则删除帖子： 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 );;
}
}
在第一种模型中，这种必须依赖DAO才能完成的逻辑行为必须放在单独的业务逻辑对象中，而第二种模型，这种业务逻辑行为也是放在实体类本身完成的。 这里唯一有点不同的地方在于，DAO是否通过IoC注入，根据上面potian的说法，他认为用Type1方式注入会比较好些，而我这里是Type3注入。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
引用 第一种模型的依赖关系是
business object --> DAO --> persistent object(实体类) 第二种模型的依赖关系是 domain object(including business logic) <---> DAO 我所用的第二种模型的依赖关系是 domain object(including business logic) --> IDAO <-- DAO |
| 返回顶楼 | |
|
发表时间：2005-03-23
Lee 写道 引用 第一种模型的依赖关系是
business object --> DAO --> persistent object(实体类) 第二种模型的依赖关系是 domain object(including business logic) <---> DAO 我所用的第二种模型的依赖关系是 domain object(including business logic) --> IDAO <-- DAO 的确如此，domain object(including business logic) --> IDAO <-- DAO 这才是正确的依赖关系。 IDAO 实事上 ，应该同属于业务逻辑的一部分，打包是应该和DM在一起的。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
七彩狼 写道 继续上面的话题，楼主的题目是“是否应该让实体类具备丰富的业务逻辑？ ”。
实体是什么？ 业务逻辑是什么？ 这些都是很令人混淆不清的概念，到底是什么应该放入到什么之内呢？ 0。实体，应该是指 EJB 或 Hibernate 下 ORMapping 与数据库ER关系图相对应的对象图，只做为数据的载体。 1。CRUD是业务逻辑吗？ 不是，CRUD只不过是系统架构提供给业务实体的一种基础服务，就是是操作系统的IO一样，它不是业务。 2。复杂查询是业务逻辑吗？ 是的，再自然不过了，复杂查询，所谓复杂，是有其业务含义的。但是，他应该放在实体之内吗？ 不应该。就像Robbin在前一派帖子之内所提到的，象这种查询，是无状态的操作，并不会改变业务实体自身的状态或属性，所以更合适的位置，应该是 Service 或是 XXXBizObjManager 之内。 3。那倒是什么是业务逻辑呢？我无法给出准确的定义，在业务范畴之内，抛去前面两种所说的，剩下的这些，才应该是放入实体之内的业务逻辑。例如：业务校验，业务计算，业务规则等等。 通常我们的绝大多数的业务，可能抛去 1、2 之后，3 几乎就没有了，这也是为什么即使现在绝大多数都采用 实体 ＋ Service ，而没有感觉到不爽的原因了，我想。 俺大部分同意这个分析！ 需要补充的是 ， 2）不仅有复杂查询这些无状态的操作，也有改变实体属性的业务操作，然而这些操作在国内大多数项目开发中，其逻辑并不是很复杂，比如需要比较别的实体或者是体集合数据的，大不了load出来然后作为参数再传入另一个Service的method中。 这样的逻辑最复杂的也不过如此，总归可以在Service之间得以协作以找到较为方便的解决方案！ 这种简便的解决问题的方案正如 ageo 一直强调的三种模式在各种情况下谁优谁劣不可比较一样。 然而，无论如何，Transaction Script模式即使如此方便，成功。 不可否认， 它的实体模型仍然是贫血的。 （不敢再说他是贫血的领域模型！ 这个定义似乎很值得在商妥 推敲！） |
| 返回顶楼 | |
|
发表时间：2005-03-23
Lee 写道 引用 第一种模型的依赖关系是
business object --> DAO --> persistent object(实体类) 第二种模型的依赖关系是 domain object(including business logic) <---> DAO 我所用的第二种模型的依赖关系是 domain object(including business logic) --> IDAO <-- DAO 我上面写的DAO隐含的是： DAO Interface + DAO Impl ,就是你们所谓的IDAO + DAO(非常痛恨IDAO的命名方法，MS的命名风格)。并且你们的第二种模型依赖关系画的也是错误的，因为IDAO也需要依赖domain object，domain object和IDAO接口是双向互相依赖的关系。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
现在的分歧比较清楚了。第一种方式就是BO+实体类。第二种方式就只有BO。
robbin的第一个图是对的，我也是这个意思，也是省略了 第二个图有问题，BO是依赖实体类的，少画了一个依赖。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
吵架贴已删，请继续技术讨论
|
| 返回顶楼 | |
|
发表时间：2005-03-23
真正写过这种程序的人都知道，DAO的接口和实现放在同一个包中根本不可能！否则两个包循环依赖了，先编译谁呀？
|
| 返回顶楼 | |
