Hibernate has Problems, but where is the Alternative?

coredump

FROM：http://blog.schauderhaft.de/2009/10/18/hibernate-problems-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 myperspective 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 alway think “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.

yuba

ODBMS

ritz

iBatis

coredump

RDF, OWL,