Hi all,
I have to begin a medium-sized project in Java, but I'm not a big fan of ORMs in general so the question is: Should I design the project with an ORM in mind (for later use) or not?
The RDBMS is Oracle 10g and the queries will be very coupled to Oracle syntax/functions (i.e. text, mining, CONNECT BY, etc...).
Thanks a lot.
You might want to look at this earlier question which discusses the benefit of ORMs: http://stackoverflow.com/questions/398134/what-are-the-advantages-of-using-an-orm/398182
The most relevant part (taken from the accepted answer):
If you have complex, hand-tuned SQL, there's not much point in using an ORM.
If you are constantly reaching past the ORM and writing your own SQL, the ORM might just end up getting in the way.
Since Im not allowed to comment your post Ill comment like this(lack of points).
Would be good for the discussion WHY you dont like ORM.
Imo, I would go for it. And if you for some reason find a query that is slow by the ORM, then I would make it myself. Just because you use an ORM most of your tasks does not mean you have to use it for all. But yes, it would be preferred.
Another advantage with an ORM is that it will look very good on your CV. Most jobs being advertised today (at least Java devs) require some knowledge of ORMs. So if you have the chance to work on a project I'd choose Spring and Hibernate as it will really boost your CV.
I thought the link to the other question covered the technical benefits rather well so I'll not say anything about them.
Yes. ORMs can take a lot of burden off of an app developer; at the very least, designing with them in mind shouldn't add much burden to the design, and can help significantly in the future if you decide to go with an ORM.
Like others have mentioned; if you are heavily (relational) DB dependant, ORMs give litle and just add not-so-useful abstraction. But most importantly: do you (want to) deal with data as Objects or not? If yes, ORMs are designed for that. If not, why bother. And you can add ORM later on if need be -- may take bit more time than upfront, but doing the reverse (weed out Hibernate after it just gets in your way...) is much worse.
But there are also differences between ORMs; iBatis might be better fit than Hibernate, for example (there are other questions for this particular topic).
I personally have found them (well, Hibernate) to be an incredible time sink. Far from saving time, I have spent way too much time trying to figure out what the hell it's actually doing under the covers. As others have mentioned, if your data model grows beyond a certain complexity, having another layer between you and the DB just creates more friction. If your data model isn't that complex, well, then you don't really need ORM anyway.
I do recommend having some sort of abstraction to keep SQL out of your Java code, but that can be done simply with a DAO layer and property files or whatever. Also tools like IBATIS or Spring JDBC can be helpful, since you can still write your own queries, and just use the framework to help with all of the boilerplate code for shuffling data between JDBC and your Model objects.
PS: amusing side note. In my office we actually have a framed picture of Gavin King that we all curse in effigy. "Hey, it's your turn to deal with today's Hibernate issue, so here's Gavin." :-)
An ORM intentionally decouples your working objects from the database, creating an abstraction (inevitably with leaks). So you'd just end up tunneling back through to restore what you'd intentionally eliminated.
If a lot of your application is intentionally implemented in the database, then an ORM just adds noise to your signal - and attenuates the signal.