Domain Model Programming With the Zend Framework

Each application I write tends to be an evolutionary successor to the previous and I suspect this is the case for most developers. With long term projects one tends to find things that work better than others, and methods that end up being a real pain in the ass and not as scalable as hoped once the code line count breaks a couple thousand or so. When I first got hired on at eROI I’ll admit my php was a bit rusty. I was fairly comfortable with it as I had developed a grab bag of small sites using procedural php and mysql, and I had a good understanding of the language as a language junky. It was fortunate that prior to working at eROI that I had delved head first into the world of Ruby on Rails and various python frameworks all of which allowed me to bask in the goodness that is MVC (Model-View-Controller architecture). As a result when I came on board with the charter of deploying large scale applications in php, my first goal was to figure out how to make php less painful and how to deploy the design patterns I had grown accustomed to.

The Zend Framework was the perfect toolkit for these ends as it provided all the abstracted functionality I could want. The first site I built using the framework was pretty cool but I’ll be the first to admit I’d sooner have a foot amputated than have someone look at the code. While I had experience with MVC, I was still pretty green and my controllers were embarrassingly bloated with logic and manual manipulation of model objects. Controllers had an unmaintainable knowledge of model objects and even minor edits proved to be disastrous as a fix in one block of code would break another somewhere else. Learning is fun. Fortunately, that website never saw the light of day. When the next major project landed on my desk, I was chomping at the bit to apply all of the lessons I had learned from the previous abortion of code. Like a good little programmer I took the logic out of the controllers and pushed it into the models resulting in a much more maintainable codebase. That website did get deployed and has been extended multiple times without much ado and has proved to be a delight to work with.

The following few projects, naturally, were built on evolutions of that same codebase, each one more abstracted and generalized than the one before. I’m a big fan of reusable code and have this vision of doubling my productivity every six months or so by applying the right technologies and re-purposing black box code whenever possible. I can’t say for certain if I’ve stayed true to the road map, but I have noticed that the projects get larger and more complex but development time is remaining the same so I must be doing something right. (I know I’m rambling on but bare with me, I’ll get to the topic in a moment). The last project I did was enormous. I started to see my coding methods strain under the pressure of the demands of the application and maintainability started to slip a bit. It was time for a major evolution.

Enter: Domain Model Programming. I’m a total newb to this design pattern so I won’t comment much on it and instead refer you to wikipedia’s description. In a nutshell the idea is to separate out the true business logic from the persistance layer implementation. I first encountered the concept here on the blog of a huge Zend Framework contributor, during a search for some annoying abstraction problem I was having and when I read Matthew’s article a light bulb went on. Introducing this method to my coding has had the effect of allowing me to break the sound barrier and accomplish the true abstraction that I have needed for real re-usable objects. So now I am going to introduce how I have implemented it using the Zend Framework.

So recently I decided to try out the Doctrine ORM library in place of the included Zend_Db module and in short I haven’t looked back. This made for a perfect opportunity to show how the database implementation can be made to be completely interchangable without having to recode the models or change any of the application specific logic. The point is the models, controllers and views have no concept of the persistance layer so it should be a breeze to swap out Zend_Db for Doctrine, and should that approach go south, it’s no effort to switch back, or replace both with something else entirely.

So first things first. Let me introduce everyone to a series of base classes that can be re-used in any project. These classes provide the base functionality that this design pattern needs leaving the models themselves free to only concern themselves with the application itself.

This is the class that all models extend. It’s purpose is to provide general CRUD functionality. The idea is that a model represents an object that has attributes and an interface to save itself. With that in mind, the base class manages an attribute array and an object that we refer to as a gateway. The gateway is the object that talks to the persistence layer so it acts as a broker for the model whenever the model needs to be saved or needs additional data from outside of itself.

This class exists solely for the purpose of acting as a collection of models. It is designed in a way that allows for lazy loading of classes. As you can see, the collection class implements some interfaces that allow it to be iterated through so we can use a standard foreach loop to step through the collection. The constructor of this class can take an array of models that have already been instantiated or an array of associative arrays describing a particular object. For example if we have a model representing a user that looks something like this:

We would be able to loop through a user collection like any other:

You may have noticed the $_model_class property which contains the name of a class (specifically a model class). This is how the collection knows which class to use to instantiate models lazily as it steps through its internal array and finds descriptive arrays. When we define our Users collection class:

We override that property with the name of our own model class allowing the magic to happen internally. Some people may prefer to not do it that way. Another alternative is to always provide a common interface on the gateway to return the proper type of object when passed the descriptive array. In that situation, the current() function would instead look something like this:

This method is probably better but either way works. So by now you are probably wondering what the hell is a gateway? Well as I said before it is the object that talks to the persistance layer (ie database, webservice, file, etc). The gateway has intimate knowledge about how to create models, how to manipulate them, and how to persist them. They can be thought of almost as drivers for web applications. It is ideal to have these adhere to an interface for a number of reasons which I will go into. So my interface looks like this:

Generally the application will talk to the gateway and ask for what it needs. The gateway will instantiate models and collections on demand and return them to the application which can be used for views. Additionally, because fetch() optionally takes an offset and limit, we can utilize the gateway in a paginator with the help of an Zend_Paginator adapter:

Application logic not dependent on persistence can be processed inside of the models and when the application asks the model object to save itself, the model will in turn ask the gateway to make it happen. As a result we have all implementation specifics housed inside of the gateway allowing for any major backend changes to be implemented by swapping out that component alone. So lets take our User example further by demonstrating what a User gatway might look like:

As you can see, the gateway implements CRUD operations intelligently. It takes data in the form of associative arrays and happily serializes the information into databases, files, etc. This particular gateway is able to determine whether an object requires an INSERT operation or an UPDATE operation by inspecting the data for the presence of an ‘id’ attribute. It is here where we implement functionality provided by the Doctrine library. So for those of you who are observant, you may be wondering, where are Doctrine’s table abstraction classes? At some point we have to extend Doctrine_Record in order to manipulate those tables. Those are stored in a subfolder tied to the persistence implementation. For this example the folder structure of the models looks something like this:

• models/
  • Doctrine/
    • Dao/
      • User.php
    • Users.php
  • User.php
  • Users.php

Here I have created a folder named ‘Doctrine’ since the implementation uses a database for persistence. This folder houses the gateway classes as well as another folder named ‘Dao’ which houses the Doctrine table models. The Gateway classes rely on the database models in the Dao folder in order to manipulate the database. Here is the doctrine User model

This class implements all of the functionality needed to manipulate the user table in the database by extending the Doctrine_Record base class. Details on how these are implemented can be found here in the Doctrine guide.

Alternately, we could also have a ZendDb folder containing the gateway classes that work with Zend_Db instead of doctrine. In this scenario our folders would look like this:

• models/
  • Doctrine/
    • Dao/
      • User.php
    • Users.php
  • ZendDb/
    • Dao/
      • User.php
    • Users.php
• User.php
• Users.php

And inside the Dao folder for that implementation we would have our Zend_Db table model.

With a little imagination we can make switching between implemenations dynamic. For those who read my earlier article on application skeletons, this can be accomplished by extending our application modules with getters for gateway objects. We can implement our module as such:

Controllers and helpers can then grab an instance of this module and retrieve the intended gateway to be used and not have to be concerned about which persistence implementation they should be using. When making the switch we can simply alter our application module to return a different gateway object and be assured it will propogate through the entire application. Now that’s easy.

So now we have a pair of classes User and Users which are 100% portable to any other application with little or no modification. Chances are the Gateway classes will be portable too most of the time. Whether we are storing them in databases, xml files, or serializing them over a REST call, we can be assured that our class will behave consistently in each scenario. This architecture also lends itself heavily to optimal unit testing which is a boon in itself.