关于refactor和OR mapping的class 的设计冲突问题

refactor的目的是为了是让code结构更好, 容易维护. 他的方法很多都是拆分class, 或加parent class, 他侧重的是class method

http://www.refactoring.com/catalog/

但在OR maping中, class 的设计是由data object mapping来决定的,
他侧重的是class field, 大家怎样来看待这个设计冲突问题.

我觉得并没有太大冲突

refactor是针对类的行为而言的
OR maping中, class主要是针对数据的结构而言的
OOP的目的就是数据的结构与行为分离，这是第一个基本要求－－封装

yyanghhong兄能不能具体谈谈呢？这样抽象的理论说服力也不大，最好我们能结合具体问题谈谈

我觉得这个问题还是绕到了yyanghhong前面提到的那个如何解决BO和PO的问题上来了。

如果严格按照把PO和BO分离的设计原则，那么Hibernate映射的PO除了getter/setter方法之外，几乎是没有业务方法的。而BO来完成相对比较复杂的业务方法。如果把BO和PO整合到一起来做，那么就会遇到何者为主的问题。我个人还是更加倾向于把BO和PO分离开来。

我就是觉得有趣, 目前数据库程序有两个主流, 一是table model, 用dataset存取数据.象 ADO.NET, 二是domain model, 以object为数据存取元素,

如果我们在po里只放数据, 用bo或dao去存取po里的数据, 这和把数据放到dataset,
再用bo或dao去存取dataset里的数据有和区别. OR mapping 的目的是什么呢?

当然是有区别的啊。数据模型不能够直观的表达例如继承关系，聚合关系，组合关系这些明显带有对象含义的模型。而这些对象模型在一个构造良好的框架中又是不可避免的大量使用(虽然有很多成功的框架也是使用数据模型，但是表达业务逻辑关系会显得比较晦涩，难于理解)。

我认为Po放数据作为和hbm.xml结合作为数据字典用，dao通过冬眠来访问数据库，然后由bo来根据具体业务组织事务（看了这里很多讨论我认为有bo来组织事务显然比用dao来组织事务更灵活，应为对数据库的访问是否编在一个事物里显然改由业务决定！）这样对
bo来说访问的就像是对象数据库一样了！

看来or mapping的发展结果就是对象数据库了.