I have had to use hibernate for a small project.

In the past I have generated partial classes from database meta data as the starting point for DB related applications. I then put the Business logic in the another partial class of the same name.

Its *very* easy.

Hibernate however is a big learning curve. When is it worth it ?

When something breaks you still have to know how the DB / optimizer/ query plan /.... works *as well* as the guts of hibernate ( megabytes of source, dozens of API's).

So far I use it only because it is mandated, I cannot see the value it adds.

Starting with hibernate on a small project is great for learning hibernate, but of course you won't see much of a benefit.

You get the most from using hibernate when you work on applications

- with a lot of CRUD. Without hibernate for a single additional attribute you need to change 5 places: java, sql for insert, read and update and the database. With hibernate only 2 places: java and database. If you generate your database from the classes (which I recommend if feasable) you only change the java code.

- with a rich domain model. If you have to do more then simple datamaintanance, a rich domain model (http://martinfowler.com/eaaCatalog/domainModel.html) is a valuable asset. But with handwritten code it is very difficult to decide which objects need to get updated in the database. With hibernate you can descibe this in a declarative manner. This is a very powerful tool.

- Hibernate gives you very powerfull tuning options which are in a sense are more effective then what your database or sql offers to you. With sql and database tools you can tune effectively complex statements, but 99% of the sql statements you need in applications as described above are realy simple. Either directly accessing one table through some id, or straight forward joins of tables. There is really not much tuning needed in this area bejond some indexes. Much more interesting is to control that only what is needed is loaded and only once. And this is done by hibernate in the form of lazy loading, and the 1st and 2nd level cache + the various fetching strategies.

And of course if you really need your dose of sql tuning - you can define your own sql for hibernate to use. Which of course should be the exception.

Of course there are applications that wont benefit from hibernate to much:

- Reporting systems or similiar, which use many complex statements (e.g. analytic functions and the like)

- Any kind of batch processing.

- Applications that are so small, that the time for downloading the most current hibernate libraries becomes a notable part of the development time.

But in order to benefit from hibernate one really has to understand hibernate, especially that it is more then a jdbc replacement. It is a completely different way to communicate with the database.