Technology weblog

Wednesday Apr 06, 2011

Why object-relational mappers are dead

Do you recognize the following nuisances?

  • Lazy loading exceptions?
  • Compromises in your domain model because of persistence requirements such as the necessity of abstract classes that don't really represent any business entities or mandatory empty constructors?
  • Issues related to cascading deletes?
  • Persistence meta data residing in your (domain) objects, such as persistence related annotations?
  • Debugging nasty (performance) issues with (generated) queries by the mapping framework?

If not, you have never seriously been involved in using an object-relational mapping framework such as Hibernate, iBatis or EclipseLink (or JPA for that matter).

Even more so, the solution to all these problems is so simple, so elegant and so readily available: CQRS.

First of all, applying the CQRS pattern disposes the object-relational impedance mismatch all together.

At first sight it seems that a mapper may still come in handy for mapping objects on the query side to the various tables. But we found once more that a simple JDBC approach is to be preferred since:

  1. The mapper makes it impossible to make the member fields of the objects in the query model final (i.e. real value objects).
  2. Persistence meta data lingering around in the objects of the query model.
  3. When you share general classes (such as an IsinCode class) in your query side domain objects, those need to be provided with persistence meta data too!
Taking all of the aforementioned arguments into account, this can only lead to one conclusion: object-relational mappers are dead!


Post a Comment:
Comments are closed for this entry.

Hire us