> Use Hibernate for the stuff that it is good at. Sure, but that's a bit circular. I find that a sensible default is to write the code to match the data, not a

> Use Hibernate for the stuff that it is good at. Sure, but that's a bit circular. I find that a sensible default is to write the code to match the data, not abstract the data to fit the code. Because, if nothing else, you'll want to understand that data with another language or framework. If it's a one-off Java project that will get thrown away in a few months, whatever is fine, but most Java applications (especially enterprise Java) aren't throwaway projects. Do you know what works in pretty much every language? Do you know what will be supported in 30 years? SQL queries. Hibernate is good at some things, but if we think in terms of product lifetimes and not sprints, I think SQL is a much lighter dependency.