Hibernate has Problems, but where is the Alternative?
Scale
In a late blog post Stephan Schmidt vents his problems with hibernate and declares “ORMs are a thing of the past”
I agree to some extend:
- The SQL generated by Hibernate by default is horrible. Huge joins, with hundreds of columns, many unneeded.
- Annotations feel like dirt in your code, and maintaining XML mappings is just painful.
- LazyInitializationExceptions are a pain in the a.. neck.
But does that justify the conclusion, that ORMs will go away in the near future? I don’t think so. Of course my perspective is biased, but in the applications I build I deal typically with 200-500 tables. Just typing the basic CRUD Statement, and wrapping them into usable objects is a pain, and a lot of work, which I gladly will hand over to an ORM.
Tracking changes in objects is another task, I gladly handover to an ORM.
Even writing annotations, while being far from perfect is better then most alternatives I know.
Implementing my own caching logic? No thanx. The ORM can do that pretty well.
I think the crucial point lies in Stephans last paragraph, where he sketches some ideas for alternatives. ORMs aren’t bad in themselves. They are just difficult to get right. Hibernate did a great job. It is the first one to get wide spread usage. And most points mentioned above are a weakness in Hibernate (or JPA) or possibly Java. So my claim is: ORMs aren’t dead, they aren’t even grown up.
So what properties might a grown up ORM have?
- Usage of persistence independent annotations: The problem with annotations is: they don’t belong in the business domain, where your classes live. They are part of the persistence layer, and should stay there. But when you look at the JPA annotations you’ll find a lot that is pretty usefull in GUI context as well. For example the length of a field isn’t only important for the database but for the GUI as well. Same for validations. So I’d think, in a couple years from now we’ll have annotations (or other language features), that let us specify features of properties and references, which truely live in the domain world. And the ORMs will just utilize that information for 90% of their needs
- When the references will have more information attached to them. E.g. if it is just a association, or an aggregation, or if the M in an 1:M relation is ‘big’. And ORMs will use that to optimize there SQL.
- The management of Sessions will move toward a declarative style, just as transactions did in the last decade.
- RDBMS vendors will finally realize the power of ORMs, and will provide more efficient protocols for the ORMs to communicate with.
- ORMs will monitor how they are used for a certain application, and will use that information to improve the SQL used.
But as so often, the most important change will be a people change: People will finally let databases drop into the background where they belong, and manage the schema through the ORM. I always wonder “Why?” when I hear people describe how the build a database first, and then map classes to the tables. That is the wrong way around: Build a strong domain model first. Let the ORM create a database schema for you from that. And then get someone with strong database knowledge involved to tweak it where necessary. This is when you start seriously gaining something for your struggle with the ORM. Most importantly: you get strong support for database refactorings.
If you want to read more about the whole ORM discussion, you might be interested in this article by Debasish Ghosh.
Hello,
At least half of your points are already addressed:
– check out Hibernate Validator and Bean Validation (JSR-303) for annotation based constraint declarations: they integrate with Hibernate already
– I am not sure what you mean by big reference and adjusting the SQL. There is a bunch of annotations to adjust the SQL already (for example @Fetch)
– the Session lifecycle is already managed in EJB 3 and in an even better way in JBoss Seam. I don’t open / close my sessions anymore and with Seam I don’t have LIE
– certainly JDBC could evolve to allow multi selects etc, but I doubt that will make things significantly better. Let’s see if someone comes with a good idea
– There has been several prototypes using AOP to monitor and self adjust ORM configs but none have been taken seriously by application developers so far. Either they are not mature enough or people don’t trust / like them and prefer the manual approach.
“Annotations feel like dirt in your code, and maintaining XML mappings is just painful.”
“The problem with annotations is: they don’t belong in the business domain, where your classes live.”
I had the same concerns, however I found a solution. I am using the JPA API but I still keep using xdoclet to automatically generate xml mappings! The downside is that meta data kept in Hibernate proprietary form.
There are always lightweight solutions: http://jodd.org/doc/db/index.html
ibatis
– dead simple
– ibator to gen your persistence domain pojos and daos
– 1 jar
I am by no means a Hibernate fan boy, but those points in which you agree with Stephen are pretty weak in my opinion. Let me clarify:
- The SQL generated by Hibernate by default is horrible. Huge joins, with hundreds of columns, many unneeded.
I think most of the SQL Hibernate generates is fine. In most of the cases, even if it appears bulky, there is no performance hit when it is actually executed by database. If you feel you’re selecting more columns than you need, maybe you need more fine-grained objects in your domain model. If there are too many joins, you are probably using too much EAGER fetching.
Furthermore, you can use custom (native) SQL and still populate the domain objects, if you feel like it.
- Annotations feel like dirt in your code, and maintaining XML mappings is just painful.
This is extremely subjective. I like having annotations in domain classes, since persistence is a key feature of those objects. You can minimize the amount of them by using proper NamingStrategy, so Hibernate can deduce column, table, foreign key names without you specifying them directly.
And the cost of maintaining XML mappings has been blown way out of proportion. Some of the info contained therein can be deduced either from Java side or from the database, but still, how often do you refactor your domain classes and/or database from the ground up? Someone without prior exposure to Hibernate would think there is some kind of magic involved with mapping files, but, in reality, they are quite readable and editable.
- LazyInitializationExceptions are a pain in the a.. neck.
They are no more pain in the neck than, say, NullPonterExceptions. They simply signify the data you ask has not been loaded from database. What would you expect Hibernate to do. If the data is not there, you can either:
1) make sure you fetch it, before you operate on it
2) leave the session open, so Hibernate will do that for you (say, by means of OpenSessionInViewFilter)
Lastly, I wholeheartedly agree with your last paragraph.
Another lightweight solution:
http://ujoframework.org/presentation/
as Emmanuel said already, no more lazy initializations using the proper framework; If I see one, I know someone is doing dirty code or the configuration is wrong.
I’d add that also the Sessions are now declaratively scoped, it really comes up in updating the frameworks people are using.
About “1:M relation is ‘big’.” that’s also a thing from the past, you can get the behaviour you want, annotating properly. Sure, as a developer you have to know what you’re asking for.
About the generated SQL, I might be not a DB expert but I’ve learnt a lot from the generated SQL, when you test it out it’s often better than what I would have written. That doesn’t mean it’s approaching perfection, but is far from wrong and much better than the average developer.
I really agree with the conclusion; it’s since 3 years know that I lead succesfull project in which the goal is to create a good domain model first, and then have Hibernate generate an appropriate schema. If the schema doesn’t look right, we go back to the model and see what we are doing wrong. It’s more a kind of feedback/validation than the starting point. So definitely Hibernate is maturing, even if many new features are coming, but most people can’t – or don’t want – get the best out of it.
btw, I’ve experienced ibatis: it might be simple, but far from the usefulness, too much work to get stuff working.
Annotations might not be heaven, but are by far the most practical option available.
Thanks everybody for the comments. (and for the votes on dzone)
A couple of comments to various points:
- I know how to get hibernate the Eager/Lazy loading I need. What I complain about is that in doing so, I annotate domain model with stuff that really belongs in the persistence layer.
- Lazy Initialization Exception: You are probably right about the frameworks. I used Hibernate in a two tier application. Session handling is much less explored in this case
- I don’t think persistence annotations on domain classes are a ‘subjective’ matter. But I do agree that they are better then XML. And I only have a rough idea, how it could be done in a cleaner way.
- I looked at some of the simpler frameworks like ibatis. Its not a direction I want to go.
And since I get the feeling at some got it the other way round: I do like hibernate and will probably use it in the next projects. But I do see room for improvement. Would be strange otherwise, wouldn’t it?
Apache iBatis.
[...] ORMs are a thing of the past – Another opinion that might get in the way of hibernate fanboys. We’ve had our share of hibernate “experiences”. It’s a useful tool if you know how to use it – and when not to. Replies followed instantly, here are two noteworthy ones by Scot Mcphee and by Jens Schauder. [...]
Some of these points you have raised have already been addressed in existing ORM’s like Ebean ORM. (http://www.avaje.org)
- LazyInitializationExceptions
—————————————
Other ORM’s including Ebean ORM don’t throw a LazyInitializationExceptions. That’s a Hibernate specific approach.
- The management of Sessions …
——————————————–
Some ORM’s are design/architected to be “session less”.
Ebean ORM for example doesn’t have an object equivilent to the Hibernate session or JPA EntityManager. Another way of saying this is that Ebean ORM provides “automatic management of the persistence context” – which is what you seemed to alude to.
As you probably know, the point of that is to remove the need to manage the “session” objects which makes life easier much for the developer.
Aka ORM session objects (like Hibernate Session / JPA EntityManager) are an architectural design decision and not required/used by some existing ORM’s today.
- ORMs will monitor how they are used for a certain application, and will use that information to improve the SQL used.
——————————————————–
“Autofetch” defines exactly this behaviour. The application is profiled and from this information the ORM can automatically tune the queries fetching only the properties required.
Ebean ORM has had this feature for about 1 1/2 years. Works very nicely with Ebean’s “partial object” support (which is mostly absent from JPA).
Refer to:
http://www.cs.utexas.edu/~aibrahim/autofetch/
http://www.avaje.org/autofetch.html