Domain Model ORM Adapters

So I’ve had a series of articles that focus on domain model programming methodologies and most of my examples have demonstrated implementations using the Doctrine ORM (Object Relational Mapper). Given the nature of domain model programming I’ve held to the assertion that models built using this method are truly ORM agnostic and it should be effortless to swap out Doctrine for the ORM of your choice. Well I like to put my money where my mouth is by showing how easily this has been done by showing off adapters that I have written, one for Doctrine, and the other for Zend_Db. The beauty of this system is that both support the same ORM agnostic query syntax demonstrated in my recent post about creating complex sql queries using associative arrays. This means that no modifications are necessary in the models, controllers or views when switching ORMs. Developer’s utopia.

I will be building upon the foundation I have laid in past articles so you may want to catch up:
Domain Model Programming with the Zend Framework
Doctrine, Complex SQL Queries, and Paginators

First we will revisit the Model Gateway base class which all model gateways will extend. This implements a gateway interface to ensure compliance for our paginator adapter from the previous articles.

We’ve seen this class before in the previous article. The bulk of the code is centered around building queries using Doctrine’s DQL query language adapted from my associative array syntax. The algorithm has been upgraded and tweaked since so there are some minor differences but for the most part it is the same. One major change is how primary keys are referenced. Early on I used ‘id’ as the primary key by convention but as I wrote the ZendDb adapter, I ran into some roadblocks that made this an unwise assumption that everyone would use this so I made the primary key name configurable in the base class. This is the class that application model gateways will extend should the developer prefer to use Doctrine for the ORM.

For example:

And voila, you’re done with your model gateway for your AppUser model. This simple class commands the full might of CRUD for the Doctrine ORM.

Now let’s see the ZendDb adapter.

This is an identical implementation of the same query builder functionality. You can see that instead of converting our queries into DQL we are now converting them into queries through Zend_Db_Select objects. The application level gateway class is none-the-wiser and requires no modification when switching ORMs.

I should inject a minor footnote/caveat here with the ZendDb adapter however, due to the difference in how joins are handled by ZendDb, this adapter makes one minor assumption through necessity. In order to mimic the join alias functionality that Doctrine supports, joins are done using joinUsing() which assumes the local/foreign key both share the same name. This differs from Doctrine which allows the keys to be different. Keep this in mind and you should have no trouble using join queries.

Using ORM adapters may seem a little bit overkill from the perspective we have added an abstraction layer to another abstraction layer but it is a necessary step to acheive true separation of business logic and the persistence layer. Additionally regardless of the ORM used, data models can remain modular and re-usable across projects. Supporting new ORMs is simply a matter of writing a new adapter.