Starting around 2000, (Java) developers figured out, that accessing relational databases using "plain" JDBC is a rather dowdy activity (a pain in the ass, one might call it too); moreover the differences in object-oriented design and relational databases got
too obvious. As a matter of fact around that time a significant number of (partly Open Source) projects were founded to deal with that problem in creating frameworks to map between objects and relational databases in a more elegant way (
Hibernate,
Castor,
Cayenne,
OJB,
Torque,
DODS,
Toplink,
iBatis just to name a few). Interestingly enough, object-oriented databases were at that time already more or less dead (except for some niche-applications) and XML databases were
not yet dead and still sounded promising at that time ;-)
All this was and is accompanied by different emerging and disappearing standards (Jürgen Höller got into details
here).
Hibernate... However, today it seems, that we are in a settlement phase. At least in the last one or two years persistence in Java was nearly used synonymously with Hibernate, which is actually a pity. Hibernate is a powerful framework, no doubt, but by good reason recently many developers detect that using a full-blown O/R mapping solution like Hibernate is not always the best idea: Some go even so far to claim, that the whole idea is more or less flawed. The critics claim - and it might not be completly wrong - that frameworks like Hibernate let you start rather smooth, but the longer the project runs, the more you are fighting to get Hibernate do what you actually want it to do (performance, functionality). And to do so, you are forced to work on a low level with Hibernate, HQL, SQL, the Caching framework and whatnot, trying to get mappings so that the desired SQL statements are produced or injecting SQL statements into the framework and workarounds like that.
I do not want to go into details here, I just want to recommend the article from
Ted Neward here. What I really do not like about this article are the references and comparisons to the Vietnam war, which is rather stupid and mostly unnecessary in my opinion, still, you can easily skip that part and go to the technical part, which is definitly recommended to consider.
...and the Rest of the Crowd?So, is there a life
after or
instead of Hibernate? I think yes: first of all there are very interesting alternative persistence technologies like
db4o based on direct persistence of object-graphs, which was also presented at our persistence event and I wrote a brief
article recently. But also on the "relational side", there are several alternatives, most prominently I want to mention
iBatis.
Apache iBatisiBatis goes a very different way and is actually not an object/
relational mapping tool it is better described by saying it is an object/
SQL mapping framework. To get a iBatis application running you need the following artifacts:
- A relational database and a schema (tables, views, stored procedures, constraints ...)
- iBatis configuration file
- iBatis SQLMaps
- recommended: Spring as DAO framework
The configuration is best done using the
Spring-Framework SQLMaps support (the iBatis team meanwhile stopped the development of their own DAO project and recommend to use Spring), check out the details there. Then you define mapping from objects to SQL statements like so:
So actually for all operations SQL statements have to be written (typically insert, update, delete). Depeding on the statement iBatis maps the parameter (
parameterClass) or the result (
resultClass) to objects. This is done automatically (in simple cases) or by creating a mapping declaration, where the mapping can be adjusted in details. In the Java DAO class the statement can be easily executed using the Spring template:
getSqlMapClientTemplate().update("updatePerson", person);iBatis Learning Curve and TransparencyIt is obviously not possible to introduce a framework thoroughly in a BLOG article, but I want to emphasize, that the learning curve for iBatis is a rather easy one plus the documentation is good and the mailing list helpful. For a skilled developer it should be possible to have the first iBatis application running within some hours.
An additional advantage (and disadvantage, depending on the point of view) is the fact, that using iBatis it is practically always clear, what's happing behind the scences (in contrast to full blown O/R mappers like Hibernate). Or as Bruce Tate expressed it:
"iBATIS is a JDBC helper framework that gives you some of the benefits of OR mapping and usage, but without as much risk."
But this reduction to mapping objects to SQL statements might also be a clear drawback, when you wish to gain a "better" abstraction from the relational database.
What now?
Which framework to choose is actually a difficult decision. But one is for sure: taking Hibernate "by default" is most probably not the best decision. Hibernate & Co are powerful but very complex integration frameworks with a high level of abstraction, defining own query languages to be learned; and a lot of mapping and configuration options are offered, which you better want to know in detail. iBatis on the other hand is very straightforward to learn and use and allows to easily use all functionality of the database without using framework "backdoors".
I suggest to have a close look at the options and decide carefully, but one thing is clear: Hibernate should only be used, if a skilled Hibernate (Castor, OJB, ...) expert is available or one person of the development team is willing to spend some amount of time to get one. Otherwise severe issues can be expected, probably at a time close to software delivery.
And not to forget: iBatis is available for Java, .net and Ruby and works with all databases (in the Java context) where a proper JDBC driver is available.For more information about iBatis I suggest also the following resources:
