General J2EE: How much should we 'ORM' ?
We're in the way of refactoring our J2EE Persistence Tier, which (until) now has been implemented by a in-house persistence framework. The matter is now whether to adopt a traditional ORM tool (Hibernate), or a SQL-centric solution (iBATIS?) as an "inverted" ORM tool.
- Posted by: Gianluca Gaiotto
- Posted on: October 05 2005 10:58 EDT
It seems that iBatis well suits in the following conditions:
- software shops who are already comfortable working with relational databases and know how to craft perfect SQL queries to interact with an enterprise database
- project teams which includes a strong DBA function
- projects that need to integrate with an existing legacy database.
On the other side, Hibernate could be useful when:
- you control the data model
- you're working with a rich object model, and want to be able to store it flexibly, easily, and efficiently
- you don't want to argue in terms of the relational model.
When i review Hibernate, i get the sensation that will work fine with a new project, starting from scratch in the Data Model, but i feel that will get complicated if you dont have a well defined Data Model, like a legacy data model.
Seems like my comments are also questions:-)
We've just finished upgrading our persistence tier with Hibernate, off of a mid size database...
middlegen->hibernate hbm.xml(xdoclet tags)->java classes
this was the approach we used with very good results. even though we had a legacy database in place with data already populated, middlegen mapped the database pretty well initially. after the initial reverse engineering to java using middle gen, we just let the java classes drive the configuration files...
I would recommend Hibernate. I have converted two existing systems with legacy databases (admittedly both quite small ones) without any real problems. I have also had very good experiences with the framework for new solutions.
Naturally it is better if you have control over the data model, but it is not strictly necessary. Hibernate is rather flexible.
However, if your current in-house framework is similar to iBATIS that would be a strong argument for going that way instead.
Let me try to answer that in general terms.
If you have an existing database to deal with, you will need to look at the data structure and decide if it's suitable for an object-oriented approach (can I turn these records into sensible objects?) or if you need to take a minimalist approach (for each record type, create a bean that holds the data but has no, or minimal, functionality and put the functionality elsewhere in the application).
On the other hand, if you have no existing data to deal with, the answer depends on the objectives of your project. If you're aiming at a massive system where you need to tweak every ounce of performance out of it, you probably want to use JDBC and SQL directly and take every advantage of the database's specific capabilities (stored procedures, etc.).
Finally, if absolute performance is not a requirement, I'd suggest doing as little ORM as possible -- let the persistence layer take care of it. There are products like Persistent Java Objects (http://www.persistentjavaobjects.com) or db4objects (http://www.db4o.com) that will handle all the database details for you and will not force you to bend your object-oriented design to handle database implementation issues. And, yes, as the developer of PJO, I have to declare a bias!