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:
- The mapper makes it impossible to make the member fields of the objects in the query model final (i.e. real value objects).
- Persistence meta data lingering around in the objects of the query model.
- 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!
05:28PM Apr 06, 2011
by Zeger Hendrikse in Java & J2EE |