A Brief History of Persistence
All this was and is accompanied by different emerging and disappearing standards (Jürgen Höller got into details here).
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.
iBatis 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
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:
iBatis Learning Curve and Transparency
It 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.
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: