A heated debate started a few weeks ago initiated by members of the Hibernate team, arguing that using an abstraction framework on top of an ORM is a bad idea, citing Spring's HibernateTemplate as a specific example. The argument was that portability across ORMs is not a realistic need, and using it is dangerous and can be misleading. The resulting debate on the blog entries thread saw Spring users arguing that HibernateTemplate is not about hiding Hibernate but instead about removing boiler plate code, providing more control, and providing a useful exception mapping hierarchy (useful if you're working with more than one datasource). The Hibernate team argued that most of the boilerplate code reductions were eliminated in Hibernate 3, the need for unified exception hierarchy isn't important, and that there is "not a single" usecase that would require HibernateTemplate.
Since then. Solomon Duskis blogged an additional usecase - separating xml configuration (for query caching) from different parts of the app - in this case runtime vs. administrative. Providing a lucid last work, Shay Banon agreed with the Hibernate team but also blogged yesterday an educational look at the historical needs for HibernateTemplate while mentioning that even with Hibernate 3, Springs abstraction handles of transactions and session context for non JTA code as well as providing slight code simplification.
Still on the theme of abstractions for data access, Brian McCallister wrote a survey with code examples of sql-centric convenience frameworks over JDBC. A quick summary:
Since then. Solomon Duskis blogged an additional usecase - separating xml configuration (for query caching) from different parts of the app - in this case runtime vs. administrative. Providing a lucid last work, Shay Banon agreed with the Hibernate team but also blogged yesterday an educational look at the historical needs for HibernateTemplate while mentioning that even with Hibernate 3, Springs abstraction handles of transactions and session context for non JTA code as well as providing slight code simplification.
Still on the theme of abstractions for data access, Brian McCallister wrote a survey with code examples of sql-centric convenience frameworks over JDBC. A quick summary:
- RIFE uses a builder approach to sql statements which is very useful for dynamic query generation.
- jDBI is suitable with direct SQL and static statements and provides more control on how queries will be executed.
- Apache DbUtils "is a short-and-sweet tool which provides even less high-level functionality, but is extremely well tested and quite flexible".
- Spring provides a few convenience API's, mostly centered around the
JdbcTemplate,which focuses on making the common cases easy and portable. - "JDBC 4 (part of JDK 1.6) will include a spiffy looking convenience API that looks like an annotation based SQL-J."
- IBatis
