When Not To Use Hibernate

When not to use O/R mapping - http://www.javalobby.org/java/forums/t61413.html

• O/R tools can generate very complex SQL queries
• fair amount of effort and complexity involved in getting objects mapped, contexts initialized, and sessions managed cleanly.

When not to use Hibernate? Well, in small client apps where startup time is important, or when you have few tables, or when you need the maximum possible performance and you are comfortable with query plan analysis, batch updates, cursor locations, and so on...

Benefits of O/R mapping:

• benefits from using ORM. First, maintaining all my logic in beans was quite natural. Second, JDO Genie had a great UI for defining the mappings, and would automatically adjust your database (safely) to a new schema
• Possibly better for programmer who doesn't know SQL, should use an ORM if they can.
• Works well with using javabeans for domain data

Drawbacks of O/R mapping:

• learning yet another query language.
• precompiling classes
• hard to track down performance issues
  • Some things like deleting large numbers of objects can be difficult with hibernate - link
    • Rebuttal to this: The simplest way to handle that is for each of the Collections containing the associations in the parent object you call "collection.clear()". Calling clear on the collection will cause Hibernate to delete all the rows in the collection in one "delete from" statement, it won't load the individual rows at all. Another option is to use the Hibernate batch query system (http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#batch-direct) to delete the associated data.

Conclusion:

• Struggle of JDO wasn't worth it. can be better off using straight JDBC
• never use ORM on a small/medium DB project again

• More Advice about when to use, and when not to use, mapping

Drawbacks of JDBC

• JDBC is too verbose. Good exception handling with JDBC makes your code grow very quickly.
  • handling all the details of exception handling, resulset and prepared statement closing, and so on was very tedious.
• JDBC leaves SQL stuck in your code.
• If you don't use an abstraction layer, queries will be all over the place. This is not nice to maintain.
• A pain for performance. If you did some serious JDBC you probably already wrote a small library to handle a connection pool of Prepared Statements, caching the one you would like.
• Well detailed in Rod Johnson book "One-on-One J2EE Design and Development", and on iBatis website.

Other information:

• Favorite hibernate interview questions - http://www.javalobby.org/java/forums/t104442.html