Hibernate经验总结

Hibernate经验总结：

0、双向关联中最好是设置一端inverse＝true，一端inverse＝false。一般inverse＝false会放在多的一端，即由多的一方来维护关系，并在多的一方设置casCADe="save-update"，在单的一方设置cascade="all" 。 
1、使用Hibernate的id generator来生成无业务意义的主键，不使用有业务含义的字段做主键，不使用assigned。  
2、使用对象类型(String/Integer/Long/...)来做主键，而不使用基础类型(int/long/...)做主键。  
3、在用Integer做主键时，需设置unsaved-value="0" 而不是null或none，因为在程序中它被默认设置成了0. 
4、不使用composite-id来处理复合主键的情况，而使用UserType来处理该种情况。 Gavin King并不提倡使用composite-id，如果你不是基于已有的数据库编程，而是重新设计数据库结构，那么建议使用UserType。你可以自定义一个UserType，包括User和Goods，并且在hbm中定义该UserType为unique的，同样可以达到目的。而这种方式的好处则是不需要你来手工维护id，而由Hibernate自动维护。UserType的使用方法参考手册5.2.4节和Hibernate自带的示例中的net.sf.hibernate.test.DoubleStringType。 
5、在使用HQL的地方，结果一般不会受XML中设置的影响。 
6、fetch参数为select方式时先查询返回要查询的主体对象（列表），再根据关联外键id，每一个对象发一个select查询，获取关联的对象，形成n+1次查询； 
而join方式，主体对象和关联对象用一句外键关联的sql同时查询出来，不会形成多次查询。 
如果你的关联对象是延迟加载的，它当然不会去查询关联对象。 
另外，在hql查询中配置文件中设置的join方式是不起作用的 
7、使用full join fetch 与 right join fetch是没有意义的。 
8、添加数据、删除、更新操作时，将同时更新二级缓存。这就是Hibernate做批处理的时候效率不高的原因，原来是要维护二级缓存消耗大量时间的缘故 
9、unsaved-value 属性在Hibernate3中几乎不再需要。 
10、单向关联更加难于查询。在大型应用中，几乎所有的关联必须在查询中可以双向导航。 
11、在两层结构中，把Hibernate Session从JDBC连接中脱离开，下次需要用的时候再连接上。绝不要把一个Session用在多个应用程序事务(Application Transaction)中，否则你的数据可能会过期失效。 
12、在系统中对性能要求很严格的一些部分，某些操作也许直接使用JDBC会更好。但是请先确认这的确是一个瓶颈，并且不要想当然认为JDBC一定会更快。如果确实需要直接使用JDBC，那么最好打开一个 Hibernate Session 然后从 Session获得connection，按照这种办法你仍然可以使用同样的transaction策略和底层的connection provider。 
13、当异常发生的时候，必须要回滚 Transaction ，关闭Session。 
14、多对多连接用得好的例子实际上相当少见。大多数时候你在“连接表”中需要保存额外的信息。这种情况下，用两个指向中介类的一对多的连接比较好。 
15、绝大多数的查询并不能从查询缓存中受益，所以Hibernate默认是不进行查询缓存的。如若需要进行缓存，请调用 Query.setCacheable(true)方法。这个调用会让查询在执行过程中时先从缓存中查找结果， 并将自己的结果集放到缓存中去。