ORM must go!

No ORM!Object Relational Mapping, or ORM, has enjoyed a long run of being accepted as a standard paradigm for middle-tier, server-side software work with a back-end database. It’s wide spread and “no-brainer” status originated, probably, with the popularity of a single, exceptionally successful Java framework called Hibernate. The idea behind ORM is blending the line that separates the middle-tier and the persistence layer and making them practically one piece. So-called persistent objects become something that simultaneously belongs to the persistence layer and the rest of the application that works with them – often even in the presentation layer.

I have had issues with ORM for the whole span of its history, since the very beginning of the rise of Hibernate. My main complaints being the internal complexity and absolute lack of transparency: All those binary enhanced Java objects; hundreds of individual SQL queries fired at once to fetch an array property of an object, update queries issued in who-knows-what order and at what moment making use of unique and foreign key constraints impossible; lazy loading with presentation layer code resulting in attempts to query the database (yes, outside the transaction); the tortures of trying to express what you want from the database in JPQL; tracing bugs into the dark time-and-space labyrinths of the ORM frameworks’ internal logic for days; the all-enveloping statefulness of everything; and yes, the object equality notion for the middle-tier caching and the cluster cache synchronization issues…

Needless to say I’m glad that we are starting to see the database for what it is again: a service, with an API, with the client code sending requests to it, getting, and processing responses. The client code has full control of formulating the request before sending it. The request is sent to the database service when the client code submits it. The response is processed when it is received. Simple and effective – just as it was originally designed.

Of course, when we talk about the RDBMS, the problem of parsing two-dimensional result sets into object-like data structures that the modern programming environments expect, as well as translating updates in those data structures into the data modification SQL queries, that problem remains. And that is where we can talk about some specific solutions. But please, no ORM anymore.

Leave a Reply

Your email address will not be published. Required fields are marked *

By submitting this form, you accept the Mollom privacy policy.