This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm here to hear your opinion on a discussion I had with a colleague about ORM tools (iBatis and Hibernate).
First of all, I'd like to point out that I'm not expert on these tools, although we use iBatis at work and I read the Hibernate documentation to study it, so I'm not a complete ignorant about them.
So, I know that those frameworks save you from the pains of the persistance layer since they create and manage all the operations concerned with a database, along with all the problems concerning transactions, connection handles and so on. Using them, you don't have to write tedious and repetitive classes to save or read your model to the DB, saving you a lot of work. Or, at least, a part of it!
I say a "part" because while you don't have to bother with crud operations (unless you got some more sophisticated ones, which you probably must deal with by hand anyway), you now have to put efforts in the configuration those tools need, which can lead to manage a pletora of XML files if not more. Furthermore, it seems to me you'd also need a conversion layer to translate from your business model to the one created and managed by those tools, which usually reflects the database structure and is therefore not the best to work whit at business layer. I don't know about some tool to automate the construction of this conversion layer, although I think it would be a mess to use something like that since your business model could reach a very high level of sofistication.
In the end, what we did is move a lot of work from a part (dao classes) to another (configuration and conversion).
Which makes me loose the point about ORM tools.
So, why would you recommend to use iBatis, Hibernate or such tools ?
Thank you in advance to shed some light on this always-learning rancher.
Because they abstract away (sort of) the chasm between objects and RDBMS data.
They don't handle transactions, by the way; you still need to deal with that yourself, at least in general.
For me, the tradeoff comes when dealing with legacy databases that weren't designed with an ORM in mind--I'm not convinced they're worth it in that situation, although both Hibernate and iBatis have pretty strong tools to do the basic mappings from the DB. How the DB is organized has a lot of implications for how good of a job the tools can do.
I'm currently working with a legacy DB that has a ton of stored procs, and I'm actually using Spring JDBC (started with iBatis, wasn't worth it to me) and so far, anyway, it's been perfectly fine. For new DB schema I'd probably use Hibernate and design the DB in XML (or annotations, but I'm still not a fan of annotations for that purpose) or jump ship completely and use an OODB.
Matteo Di Furia
Joined: Jun 20, 2008
Hi David, thank you for your reply.
Could you please elaborate more on this : "they abstract away (sort of) the chasm between objects and RDBMS data" ?
I mean, unless you use the generated orm model directly in your application (which I think would be suicidal), you still have to convert from it to your business model, so this is not a complete abstraction, since you must program this conversion by hand.
Am I wrong ? I'm still missing something.
P.S. What I wrote is valid if you use a model generated from the DB. If, instead, you config XML mappings to use your business model, you would not need a conversion layer, but you'd still need to put efforts to build XML mapping that handle your business model (hence, losing the opportunity to use generated mappings).