零雨其蒙's Blog

如果一个团队，没有一个很懂Hibernate的人，却贸然使用Hibernate，这本身就是风险管理的失败；
并且团队中的成员又不是很强（因为高手组成的团队，即使之前不懂Hibernate，但是他精通SQL，精通数据库建模，精通JDBC，精通J2EE，现学也还是会很厉害），还搞个新技术去做，那么风险管理做的就太糟糕了。

我觉得咱俩的讨论就像gigix在JE上跟一个人的讨论一样，我Blog里摘录。

@shinewang
说到底，大家还是JDBC的思维太积深了。
解决这个问题也很简单，我们用泛型DAO，然后将CRUD的语义跟JDBC一致，如果搞不清楚Hibernate细节，那就不用延迟加载，不做关联映射，每个实体一个DAO~~~

因此我觉得大家伙都是专业人士，就不要看那些给学生看的垃圾图书了，放着好好的Reference为什么不读呢？

还有一点，就是学习技术最好不要看中国人写的图书，质量极差，误导性极强~~最好的方法是看Reference入门，然后可以看In Action系列~~

@shinewang
可能你理解的快速入门指南是Get Started（Reference的第一章，里面的确没有谈及Update），而我认为Hibernate Reference就是所说的快速入门指南了。而详细说明书则是Hibernate实战那本书。阅读一遍Reference大约只需要3天时间，因为一共才20章。
如果数据库，J2EE基础很差，而且一个项目的周期只有2个月，那就不要用Hibernate了，我发现很多人看了那个Reference时说看不懂，很多都是因为他连JDBC、事务隔离级别，数据库范式，和典型的开发模式都不知道，看不懂就是自然的了。
如果项目周期有两年，那么花1个星期把Reference里的内容都实验一遍，应该基本不会出问题的。
如果您有时间的话，可以写Hibernate的十大陷阱，我觉得更有益处~~~

@shinewang
1 对于延迟加载，OSIV使得你不必要关心事务，也没了托管的概念，是一种简化
2 ActiveRecord是怎么做的？无非就是约定优于配置+参数绑定。我真不知道还有什么第三种方式能能系统自动的就知道程序中的username和user_name是对应的，用怎么知道username和f_user_name是对应的，大家习惯都是不一样的。按照Fowler的说法，ActiveRecord是在Transaction Script和ORM中的一个折衷。
3 Hibernate的哲学是管理对象和数据状态，而不是做数据操作。你把他理解为数据操作就错了，实际上，Hibernate的操作是状态转换，底层才是JDBC的操作。因此这不是过度设计，只是一种理论的实现罢了。
4 最后这点确实是问题的关键，因为我们关注的方面不同。
如果是小应用，非要选择Java的话，持久层还是用iBatis或者用Spring的JdbcTemplate比较容易理解。但是，如果你懂Hibernate的话，小应用使用Hibernate同样非常敏捷，我们项目中的基础数据维护就是用Hibernate做基础，然后编写了一个通用的DAO（继承自泛型DAO），只要把实体的类set进去，然后就可以对这个实体进行CRUD操作了。另外Hibernate的属性与字段默认对照你是可以重写方法变成你喜欢的样子，比如让username自动去对应user_name（开源就是好~~）。
总而言之，并不是Hibernate有十大罪状，而是：
1 没有理解Hibernate是什么
2 不看说明书就使用家用电器。在这里我不说家用电器的事，那时我买了件马克华菲的衣服，洗了一次发现有点掉色，心里暗想这么贵的衣服怎么质量这么差。拿去洗衣房，洗衣房的阿姨告诉我，这种大品牌的衣服，在衣服的内兜或者底襟的地方都有洗涤说明的，我一看，才发现自己洗错了。这件事情告诉我，每件事情都有其内在客观规律，你必须要遵守的。

@shinewang
1 我并没有说你不会，我知道你会配置OSIV，但是你好像并不知道OSIV的来历，要不然你也不会说出是延迟加载导致了OSIV。
你也会配置Hibernate映射，但是我不知道将你的程序和数据库模式对应上除了写映射和SQL语句（或者类似物）还有什么第三种方式？既然没有，那么写映射肯定更简单，而且Hibernate提供很好的默认值，怎么会说繁琐呢。
你或许只会操作，但是并不懂得背后的原理，有些甚至都不会操作。
2 我不认为Hibernate有什么过度设计的问题，只能说明那些问题你可能没有意识到，过去我也是这样，不知道你读没读过Martin Fowler的企业应用架构模式和Gavin King的Hibernte实战以及Rod Johnson的三本书，我觉得那些在开发中我们会遇到的问题或者麻烦，Hibernate都周到的用世界级的方法帮我们解决了。
3 Hibernate3已经和Hibernate2是不同的包了，很多东西都改了，新版本只能说是日臻完善，越来越好，我是没看出来他有什么地方是妥协的。另外不知道你用没用过EJB2.1，那个东西很简单，关键是很多问题没解决啊
4 新的Hibernate那就应该是EJB3了，这个项目也是Gavin King主持的，除了标准化了基础设施，也没什么太多新的东西，毕竟ORM的理论Fowler8年前就论述清楚了，而且像Toplink这样的商业级ORM都有十年历史了

@lin
10年前就有OR不匹配问题了

作者的观点十分荒谬可笑，估计高手都懒得回复你了：
1. 复杂的实体状态
持久，瞬时，托管。三个状态非常完美的表示了对象和数据库的交互（绑定了Session，就将内存和数据库连接起来了），绑定了Session，如果一个对象在数据库中没有对应的记录，而只存在于内存中，就是瞬时的；如果一个对象在数据库中有对应的记录，而且现在在内存里，就是持久的。没有绑定Session，如果一个对象在数据库里有对应的记录，而现在它在内存中，就是托管的。
请问这复杂吗？
关于自动同步问题，只要你读过一遍那个薄薄的Hibernate开发手册，就该知道这些问题啊，不看使用说明书，就使用产品，这是很多人的通病吧。
2. Lazy Load 与 Eager Load
Open Session In View本质是一次会话一个事务这种模式，你当然可以使用托管对象模式，谁说的Lazy Load直接导致了OSIV？
3. Open Session In View
同上
4. 级联
级联删除是数据库本身就有的选项，至于级联插入和修改，以及集合元素的remove都是符合语义的，我知道你的担心，怕关联对象自动插入出现问题，计算机不是掷骰子，因此这种担心是多余的。
5. 批量更新与缓存不一致
你可以修改缓存策略，不想用就不用。更何况大型的网站怎么可能不用缓存呢，即使你不在应用层加，很多大型数据库也是会带缓存的。
6. 配置繁琐
数据库和程序是怎么对应起来的，你总得在一个地方标明吧，要不系统怎么知道你是怎么对应起来的。你用JDBC就是写insert 字段 vlaues（值），将字段和值对应起来，只不过Hibernate配置换了个地方，把这种对照关系写在了配置文件里。而且写一次就OK了，你不必写update的时候，再去看看程序中的哪个变量与数据库的哪个字段要对应上。
Hibernate提供了默认的配置，是在简化你的开发啊。
7. HQL
HQL在做些简单的查询时使用可以简化你的代码，而复杂的查询就不要用了，稍微复杂点可以用QBC，实在不行了用SQL，不同的复杂程度，用不同的解决方案，Hibernate想的很周到。好比你吃粉条最好用筷子，喝汤最好用勺，啃排骨最好用手。
8. 太多的查询方案
见上一个问题
9. N+1次查询
N+1次查询和笛卡尔乘积是一个鱼和熊掌不可兼得的权衡，Hibernate提供了不同场景的不同方案。和第7个问题一个道理，你应该使用恰当的方法。
10. 性能问题
Hibernate只是帮助你生成了一些SQL语句，创建和管理了一些对象，这两个过程你不用Hibernate也会自己做，你可以把自己写的代码，跟Hibernate执行过程做个对比，通常情况下，你写的SQL，未必有Hibernate生成的好，毕竟人家是专业的SQL专家写的SQL语句。

最后一个故事是庄子里的吧
每个故事都很好~
很受启发

PO应该和Hibernate应该没什么必然联系吧，我第一次见到这个词好像是在Core J2EE Patterns里，TO也是在这本书里见的，Rod Johnson批判了TO这样的哑对象破坏了OO，而我觉得从领域层到表现层的传递有了VO，从领域层到持久层的传递有了PO，为什么还非要TO呢？

"从概念上DTO和PO仍然属于不同层,后者才是操作数据库的."我觉得此话欠妥，PO应该是和表对应的，跟表是一种对应关系，而操作数据库的应该是DAO。最近在研究《UML和模式应用》，希望讨论之。