Hibernate best practices

1. Prefer crawling the object model over running queries
• Querying in hibernate always causes a flush
2. Make everying lazy
• First read will be slow but everything else will be cached
3. Use second level cache
4. Use cascade cautiously
• Hibernate is not good at saving a whole object tree in one go
5. Use Field access over method access
• will be faster since no relfection is used
6. Use instrumentation
7. Don't use auto generated Keys
• you have to wait until the object is persisted before its equals method works
8. Use id based Equality
9. Write fine-grained classes and map them using .
• Use an Address class to encapsulate street, suburb, state, postcode. This encourages code reuse and simplifies refactoring.
10. Declare identifier properties on persistent classes.
• Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. We recommend that identifiers be 'synthetic' (generated, with no business meaning) and of a non-primitive type. For maximum flexibility, use java.lang.Long or java.lang.String.
11. Place each class mapping in its own file.
• Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment.
12. Load mappings as resources.
• Deploy the mappings along with the classes they map.
13. Consider externalising query strings.
• Externalising the query strings to mapping files will make the application more portable.
14. Use bind variables.
• Even better, consider using named parameters in queries.
15. Don't manage your own JDBC connections.
• Hibernate lets the application manage JDBC connections. This approach should be considered a last-resort.
• If you can't use the built-in connections providers, consider providing your own implementation of net.sf.hibernate.connection.ConnectionProvider.
16. Consider using a custom type.
• Suppose you have a Java type, say from some library, that needs to be persisted but doesn't provide the accessors needed to map it as a component.
• You should consider implementing net.sf.hibernate.UserType.
• This approach frees the application code from implementing transformations to / from a Hibernate type.
17. Understand Session flushing.
• From time to time the Session synchronizes its persistent state with the database.
• Performance will be affected if this process occurs too often.
• You may sometimes minimize unnecessary flushing by disabling automatic flushing or even by changing the order of queries and other operations
  within a particular transaction.
18. In a three tiered architecture, consider using saveOrUpdate().
• When using a servlet / session bean architecture, you could pass persistent objects loaded in the session bean to and from the servlet / JSP layer.
• Use a new session to service each request. Use Session.update() or Session.saveOrUpdate() to update the persistent state of an object.
19. In a two tiered architecture, consider using session disconnection.
• Database Transactions have to be as short as possible for best scalability.
• This Application Transaction might span several client requests and response cycles.
• Either use Detached Objects or, in two tiered architectures, simply disconnect the Hibernate Session from the JDBC connection and reconnect
  it for each subsequent request.
• Never use a single Session for more than one Application Transaction usecase, otherwise, you will run into stale data.
20. Don't treat exceptions as recoverable.
• This is more of a necessary practice than a "best" practice.
• When an exception occurs, roll back the Transaction and close the Session.
• If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
• As a special case of this, do not use Session.load() to determine if an instance with the given identifier exists on the database;
• use find() instead.
21. Prefer lazy fetching for associations.
• Use eager (outer-join) fetching sparingly.
• Use proxies and/or lazy collections for most associations to classes that are not cached at the JVM-level.
• For associations to cached classes, where there is a high probability of a cache hit, explicitly disable eager fetching using outer-join="false".
• When an outer-join fetch is appropriate to a particular use case, use a query with a left join fetch.
22. Consider abstracting your business logic from Hibernate.
• Hide (Hibernate) data-access code behind an interface.
• Combine the DAO and Thread Local Session patterns.
• You can even have some classes persisted by handcoded JDBC, associated to Hibernate via a UserType.
23. Implement equals() and hashCode() using a unique business key.
• If you compare objects outside of the Session scope, you have to implement equals() and hashCode().
• If you implement these methods, never ever use the database identifier!
• To implement equals() and hashCode(), use a unique business key, that is, compare a unique combination of class properties.
• Never use collections in the equals() comparison (lazy loading) and be careful with other associated classes that might be proxied.
24. Don't use exotic association mappings.
• Good usecases for a real many-to-many associations are rare.
• Most of the time you need additional information stored in the "link table".
• In this case, it is much better to use two one-to-many associations to an intermediate link class.
• In fact, we think that most associations are one-to-many and many-to-one, you should be careful when using any other
• association style and ask yourself if it is really neccessary.