数据建模 vs 对象建模 (从Ofbiz帖子切分出来的)

借此帖帮助我消除一个疑问吧。
  通常我们需要持久的是纯粹的数据对象---只有数据没有业务操作。

  但随着如果用对象建模，极有可能存在这么一个问题，我的实体对象具有较多的体现逻辑的行为。比如，实体对象：timeRange. 它不仅具有属性，也具有行为。

  public   class   XxxTimeRange extends ITimeRange{
         private XXXX startTime;
         private XXXX endTime;
         public ITimeRange intersect(ITimeRange timeRange);;
}

 
  从软件分层次以及考虑不暴露实体对象的角度看，也即是采用DTO或者VO，那么我这个timeRange如何处理？客户程序可能要利用我的timeRange的借口。在DTO或者VO里面重复实现一次嘛？这明显不可能。DTO和VO基本上纯粹的数据对象。抑或是增加一个类似Adapeter的东西？

  此时，我们应该如何处理，

OLAP 中 I/O 是首先需要考虑的瓶颈，所以用于 OLAP 的表中都设计有大量的冗余字段。复杂的 OLTP，I/O 也会成为瓶颈。我综合 potian 和 robbin 的意见，这个瓶颈应该在系统开发之后通过优化来解决，因为这基本上是一个局部问题。Kent 说，不要为明天而设计，我的理解是出于成本上的考虑，过早地考虑一些实现细节会给开发造成很多不便。而且这些问题的影响未必真的那么大。

OLAP 不是基于关系模型的（是以 Cube 为核心的），对象驱动的建模方式在这里行不通（在这里对象建模解决的根本就不是核心问题）。

对于报表一类的复杂应用，对象建模的方式也不是很适合。以后我会把我们遇到的一些复杂的问题贴出来大家讨论。我们用的也不是数据建模，虽然我们设计了很多对象，但是很难说是对象驱动的，甚至可以说是以数据结构和算法为中心的（我们在其中用了一些很精巧的数据结构，抱歉我不能透露）。我们这个报表系统中大量对象都建立在内存中，只有适当的时候才持久保存到数据库中。也不是简单的映射到数据库中，有比较复杂的映射逻辑。

世界上并不只有对象建模或者数据建模两种东西，也不是非黑即白的。多关注一些数据结构和算法会很有帮助。虽然它有些难，但是有时候却是解决问题的利器。比如我们在内存中实现了 BTree 和稀疏距阵，还实现了向量的复杂计算。你能说这是对象建模吗？我的两个朋友在这方面有非常强的功力，掩盖了我很多时候完全依靠对象建模来解决问题所感到的虚弱。

两个考虑途径：

1、把控制方法切分出来，单独做一个控制类来控制它。

2、当需要的情况下，给PO加入一些业务方法之后，PO就变成了BO，至于BO如何和PO进行同步的问题，在Hibernate原理版有一个比较深入的探讨，可以参考一下。

http://forum.hibernate.org.cn/viewtopic.php?t=1116

能放出话说hibernate满足所有要求，这对初学者是个很大的鼓励，这可是真正的经验。
我考虑的问题ShenLi很像，也是在二者之间如何平衡而犹豫不绝，一方面可能由于对象设计的不合理，另一方面希望自己的设计是个纯正设计，不能因为运用o/r mapping，而使代码进行折中。这并不是说对象建模不好了，只能说现有的o/r mapping还没有完全解决我的问题。我觉的o/r mapping的出发点是以业务类为基础，因此对于因为数据的原因来调整，都不容易做。

  明显，这样就极端不爽了。我为了实现这么一个看来是纯对象的东西，却要引入许多如此复杂的不直观的东西。好像shenli的所说的，为了适应o/r，就不得不修改对象结构。
 
  另外，我个人反对帖子里的把 PO当做VO用，VO并非PO,两者的职责是不一样的。

    potian没有说满足所有要求......目前只能说没有遇到难以处理的情况。

因为我用 Hibernate 不多，所以没有完全理解这个问题。不过我是比较反感一些不必要的复杂性。力求简单是开发人员的最高境界，虽然这个简单很多时候是难以达到的。

??????

基本上一个应用程序里面的领域相关的模型里面需要3种对象：
1。值对象(Value Object)，没有身份，内容表示一切，譬如我和weihello都去银行里面存取100大洋，那这个100RMB是一个值对象
2。实体对象（Entity)，需要持久，不是按照内容，而是按照它的身份来区分，也就是说即使内容完全一样，也不是同一个对象。这个身份在内存里面是它的实例地址，在数据库里面是关键字，最常见的就是OID.这个实体对象并不是纯数据，它处理本身的实体模型，例如Accout，它的withDraw,它的子Account等等，它也处理自己和其他实体对象之间的关系，例如订单里面的订单行，都是应该在这个Account里面实现的，而不应该有一个什么控制类。在一个Web应用程序里面，涉及到对象关系的一般只需要一个（或几个）DTOFactory负责所有对象的DTO和Entity之间的组装和拆份，不需要专门的管理，这一部分也是和数据建模最相近的地方。
3。服务对象(Service)，这是为我们提供服务的类，譬如银行里面服务员，她帮助我们把钱从一个账户转到另外一个账户，并记录相应的交易。
对象的作用是对它自己的内部状态负责，如果它需要存取很多其它对象的状态进行运算，那叫做特性忌妒，是要重构的。应该把这些代码移到那个持有这些状态的类里面

辨别一些名词：
1。VO：实际上很模糊，通常指ValueObject和ViewObject
2. ViewObject，界面展现需要的对象，如Struts的FormBean
3。Value Object，早期被作为ValueObject和Transfer Object的总称。实际上Value Object的真正意义在于它的内容，而不是身份
4。Transfer Object：数据传输对象，在应用程序不同层次之间传书对象，在一个分布式应用程序中，通常可以提高整体的性能
5。PO：也许就是Persistent Object，基本上就是Entity了
在不同的体系结构和实现方式里面，这些对象有可能重复，也有可能不重叠。如果你要做一个对所有的体系都能够方便移植的框架，那么每一种对象都需要严格区分。例如JDO的PO不能作为TO，应为它不能脱离PM，譬如你可以选择用ViewObject（如Struts的FOrmBean)直接作为TO，但在tapestry和Webwork里面就不合适了。但在很多时候，能够方便实用是最重要的，不要过度设计就是了。