Why Hibernate ?? Most of the time, for a simple DB access, an Entity CMP is easy and efficient
Jean-Louis, I've never heard Entity Beans described as "easy" or "efficient". OK, we could have an arguement over the easy part - whats easy for one is unecessarily complex to another. Efficiency though, I will take exception to. If by efficiency you mean application performance, well Entity Beans have very well documented performance shortcomings, hence the emergence of such
J2EE patterns as "JDBC For Read". Alternatively, if by efficiency you mean development efficiency, again comparing a EJB container bound, vendor specific, heavy weight ORM solution like Entity Beans with a lightweight, platform independent solution which doesn't even need an EJB container is a bit of a non-starter.
In answer to Suneesh VR's question, I'd say use either
JDBC (via a DAO layer) directly from your sessions beans, or use a lightweight ORM solution like Hibernate, again from your sessions beans. I'd also say I'd never consider Entity Beans. I've listed these reason before, but I dislike Entity Beans
so much I don't mind listing them again:
They are not a portable solution. Despite Sun's claims to the contrary, anyone who has had to move an ORM layer written using Entity beans from one container to another will probably agree with me that it is a non-trivial task. Hibernate on the other hand, works with any container without any configuration changes.You can't pass them to the client, so they require anti-patterns like DTOs.You can only access them through Session Beans, which for many applications is not a good choice.EJB-QL is a sub-set of SQL. SQL is the absolute minimum of what DBs need in terms of a workable Query language, which makes EJB-QL less than sufficient. You can end up accessing the DB in an inefficient way as a result of EJB-QL's limitations. Hibernate's HQL is much richer, and allows direct SQL queries if they are needed.Entity Beans carry the baggage of container provided sevices with them. So you can include things like security in your configuration of an Entity Bean. Given you can only access Entity Beans via Sessions Beans, where security can also be defined, why do you need to burdern an Entity Bean with a consideration which is not really the domain or the ORM layer?Entity Beans are designed round a single entity CRUD operations. Most J2EE applications need lots of DB operations which use large, read-only result sets, something which offers cripplingly poor performance. Entity Beans force a 1-1 mapping between the object and the entity. Which quite often results in unnatural ER or OO models (depending on whether the DBA or the Developer wins that arguement). [ February 11, 2005: Message edited by: Paul Sturrock ]
