业务逻辑层下的ORM层用什么，有人推荐Hibernate，也有人对此持否认立场，所以抉择先相识一下,以下是我看了几天文档后的一些体会，大概有点灰心。
1,Hibernate毕竟能用到多大的项目？
什么是多大，这很难说，我想应该是数据库表较量多，业务逻辑较量巨大（表关联巨大），并且要求机能较量高吧。其他行业我不知道，电信行业软件都该是如此。据我相识，这样的数据库会见（尤其是频繁产生的生意业务）凡是需要用存促进程来办理，甭说本身写java的JDBC了，更不消提用Hibernate来办理。所以必定有个合用范畴的问题，但愿已经纯熟hibernate，并做个一些项目标人的人给以辅佐办理
2 Hibernate机能会多好？
许多人都说Hibernate机能好，无非是它的一些cache成果，暂时不接头是否有这样的最佳实践（但愿海内有人能提出best practices,可能pattern）,单从cache自己来说，也并不是有了就好，不然，也不会呈现漫衍式cache。就像尊长整天絮聒这，絮聒那，我外貌认为那是对你好，其实你本身心里甭说又多烦恼了。hibernate为了办理方方面面的机能，而提供了方方面面的特性，但这些加在一起就不是好工作了
3 DBA附和在项目中利用Hibernate么？
我不是DBA,甚至对写sql语句都不熟悉，所以有时候写DAO的时候常常请教DBA,DBA也很习惯的在DAO中找到他们熟悉的SQL(而不是HQL),我想这是DBA不倡导Hibernate的一个原因。别的一个原因是在于数据库自己就是一个浑然一体的系统，无论其机能照旧伸缩性（我想没人阻挡我的概念吧），因此DBA深信，能把问题交给数据库是最好的。因此他们不会附和一切都依赖Hibernate。这个概念也但愿懂Hibernate的DBA给以证实
EJB的汗青使不少人都以猜疑的立场来对待Hibernate，以前EJB怎么乐成的，Hibernate也在走这样的路，所以，我不太相信评测，只是但愿一且能从实践出发，让hibernate能淘汰开拓人员事情量，以及减罕用它的风险。
