Let me start by saying that if we need an ORM tool, Hibernate is my choice.

That said, I am in discussion with some colleagues wherein I am taking the position that the needs of our project are not sophisticated enough to pull Hibernate into the mix of new technologies we are applying.

I am basing this on the following:

Most of our DB needs are for lookups - we have about 2 dozen lookup tables. The problem I want to solve is caching of Tables, not indvidual rows (objects).

Our persistance needs are simplistic - only about 6 tables, all part of thye same object tree, and always as part of a singe transaction.

Finally - we have no Hibernate expertise on site. I have played with it, but amalready trying to mentor a team on the use of Spring and/or Struts. Hibernate is just one more framework based on the above.

Again, this is not an argument of Hibernate vs something else, but I would be interested in discussing whne others feel Hibernate would be too much, too heavy, for a particular application.

I would appreciate ANY feedback on this!

Ed

==
needs of our project are not sophisticated enough
==
That is the reason for using Hibernate! If your project persistence needs are not complex then H will make that your DAO layer very simple and convenient.

If you need to perform complex joins constantly and DB schema is not 'optimal' then iBatis might be a better choice. In any case I suggest NOT to use straight JDBC.