Over the past couple of years I have spoken to various people who have read my book and many have liked the way I implemented my Models for the Storefront, obviously looking at the design now I can see many design mistakes, some of which I did actually mention in the book. A lot of people also want to use my design in their applications and they occasionally email/tweet me to ask things, what I usually end up saying to them is the design was very focused on being an example for the book and a such its probably not what I would consider production ready code, I then normally advise them to checkout Doctrine 2 and consider splitting read and write so the Models become write only (more on this later).

With this in mind I have decided to go back and refactor part of the Storefront model, to start we can look at some of the guides we can use to improve the design.

Modelling Behaviour

One of the most important things that is missed by many examples on Zend Framework models and Doctrine is that the models usually contain little or no behaviour. When we have models like this we are usually looking at the Anemic Domain Model anti-pattern. Whilst this probably does not apply so greatly if we are not using the Domain Model pattern we can still learn some valuable lessons from it. By modelling behaviour we should end up with a simpler and more lean model, this also helps when we come change the model as each behaviour is distinct.

We can identify models that do not implement behaviour fairly easily by looking for the following factors:

• Lots of Getters & Setters
• Model methods have no "Verbs" in them
• Behaviour is found somewhere else, the model is used or wrapped to provide behaviour
• Unit tests test the data structure of the model

Tell Don't Ask

Tell Don't Ask is a style of Object Oriented Programming that states that an object should only ever tell another object to do something, it should never ask an object for its state. The reason for this is nicely described by Alec Sharp in Smalltalk by Example where he states:

"Procedural code gets information then makes decisions. Object-oriented code tells objects to do things."

So by using Tell Don't Ask it forces us to "do things" and means we have no getters or setters in our model. This may seem like a strange concept to start, as I know you are probably wondering how we display information which I will cover shortly. The main advantages here are going to be that we have a truly OO model that has proper encapsulation, it also means that we don't have lots of other code that makes decisions based on the state of an object. Not using Tell Don't Ask, we usually end up with a rich service layer that contains the actual behaviour, this then means we have models that only contain data and getters/setters, and this in turn leads us again to an Anemic Domain Model.

Separating Read & Write

Another thing that can cause us problems is mixing the Domain objects with the View (Read). If we do this we generally end up compromising our model to support various display problems, we can also get long object chains like $user->getClient()->getAddress()->getPostCode(). This will also lead us to violate encapsulation and forces us to mix display and behaviour, by doing this we cannot adequately address either problem. Also in PHP we have problems with its share nothing architecture, unlike some other languages (Java, .NET) PHP cannot store object beyond a request, this means that we have to reload our objects every request, whereas other languages can use object between multiple requests. This is not a fault within the PHP language just a fact that we need to be aware of when dealing with complex object models, indeed in other languages you have to think about locking etc much more so there is a payoff either way.

We also need to consider the use of an ORM (like Doctrine 2) here, now ORM's provide us with an elegant toolset for persisting the state of our objects, however they do not answer all our problems! When using an ORM you will undoubtably at some point need to display a few thousand/million "things" at the same time, say for an export of orders. Now what we find here is that we cannot use objects as we know we will run out of memory, therefore we end up side stepping the ORM, we choose to use things like Native Queries (Doctrine) or create a service that gets the data straight from the database. This is all very valid but if we didn't mix display and behaviour we wouldn't get this problem.

Database design is also key here, just like when the design our model, the database is designed to serve a particular task, in the case of our models this task is to persist the state of our domain. Now ask yourself the questions is this the same problem as pulling reports from the database or displaying information to the user? I would say probably not, to display a report for example we may need summary fields or calculated totals for performance, we cannot create a one size fits all database, especially if we need high performance.

Refactoring the Storefront Catalog

Right now time for some code, in this section we will go through and refactor a small part of the Storefront model and try to apply the guides above to it. For this we will keep the model really simple so we don't get over involved in the implementation, so our basic spec is that we can create products and products have a name, category and price, we can also update the product name.

You can find the code for this here: https://github.com/muteor/Examples/tree/storefrontModelPart1

First a test…..

Here we have the test-case for our basic product model which contains two tests. The first test is pretty normal and simply tests the creation of a new Product, notice that we have no getters here, this is why we are using PHPUnit's readAttribute method to read the protected properties. Another notable aspect is that we are using the constructor in the way it is meant, we intend to not have any base class that implements the construct, this means that whenever we do new Product we will be creating a brand new Product. We also use the constructor to validate our object, by using the language feature we can make sure that a new product is valid by adding the requirements into the constructor (its parameters).

The second test, tests the process of updating the products name, here we see that to do the update we do not use a setter. Instead we introduce the concept of a Command, a Command is applied to a model and the model processes it to complete the state modification. By doing this we are now only communicating to our domain in objects, this means we have a high level of encapsulation and separation.

The idea to use Commands is partly because we want a Tell Don't Ask style system, however this is also related to the Command-Query-Separation (CQS) pattern, this states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. This gives us clear markers to what methods make state changes and which ones don't, though in our models we are not going to have anything that returns state.

If we now look at the our model classes:

Looking at the Product construct we see that it takes three parameters, these are what we deem to create a valid Product. In a real world situation we would probably have many more properties that are required to make a valid Product, in this case we can sometimes find we have long parameter lists, to mitigate this consider using Parameter Objects. If we look at the body of the constructor we see that it creates the CreateProduct Command and applies it to the object via handle(). Now the new call in the constructor would normally ring alarm bells for me as new is always problematic for testing, however in this case I treat the Commands as an integral part of the model and test these along with the model, this is essentially because a Command should be a very simple DTO that we can control easily in our tests. The handle() method simply takes the class name of the Command and looks the corresponding handler, so for createProduct this is the onCreateProduct() method.

The onCreateProduct() method takes the command and applies the data contained in the command to the Product, all very simply really, though notice we use a protected method so everything is applied via handle(). Similarly in the OnUpdateName() method the handler simply takes the command data and applies it to the Product, obviously these are fairly simple examples we could have validation etc in our handlers that would throw various exceptions for us.

Finally we should look at the Commands, they should hopefully be pretty self explanatory.

Looking at the AbstractCommand class we see that it uses the PHP magic __get() method, we use this to enforce a read-only object so that the Command cannot be changed once it has been created. Both the the concrete Command implementations simply extend the AbstractCommand and define the protected properties that make up the Command, all properties are passed in the construct of the Command.

Wrapping up we can see we have a simple design and nice separation of concerns going on IMHO. Now working like this can be kept simple though if we face complex domains we can also consider using Domain Driven Design (DDD), DDD provides us with a few more tools to guide us in our modelling practices. I won't go into too much detail but if you are interested the two most important ones when working like this are Bounded Context and Aggregate Roots, though also checkout Entities and Value Objects.

Persistance

Once we have our Domain modelled (and tested) we need to persist its state, for this I would suggest using Doctrine 2, it is in my opinion a great ORM for PHP. I will be rewriting the Storefront example using it when I get some time (and when ZF2 is more stable), so you will be able to see some solid examples then, until that time the Doctrine documentation and examples online should get you started.

Creating a Read Model

So far we have no way of reading state from our models, as we have no getters. We could simply add these and use our models in the view, however I have found that this becomes heavy and has the potential to hinder performance, therefore we can create a Read Model. A Read Model can be as simple or complex as you like what we want to do though is balance our needs for performance and maintainability. We could simply have service classes that contain a range of methods that query the database directly or we could go a little more complex and implement some sort of service that returns simple DTO's of our objects.

What I have been using is Doctrine's query interface and instead of returning the mapped entities returning array or scalar values. Using this I get all the relationships handled nicely by Doctrine making it really easy to query my Domain. In cases where this is not performant I use Native Queries or use the DBAL directly.

Here is my base Read Model class:

The base ReadModel class simply wraps the doctrine query interface and provides as set of convenience methods for returning the queried data in various formats. We can then extend this class to implement domain specific querying, for example we would probably have a Product Read Model that would return products by categories etc. This could look something like this:

Going Even Further

Time to come clean, what I have been going through here is an ultra simplified version of a CQRS system by using some of the core concepts behind it. CQRS or Command-Query-Responsibility-Segregation is an architectural pattern/methodology that can be used for highly scalable distributed systems. The principles behind it are fairly simple though the implementation can be complex. If you would like to know more I would suggest starting here, this article gives a great introduction. Obviously CQRS is a very high level pattern and most of the time we do not need the type of performance etc that it provides, but I believe we can learn some valuable lessons from the concepts that drive it, also by using what I have shown here you also have the option of refactoring into a more CQRS like system in the future.

Wrap Up

So this article represents my current view on modelling in PHP, this is all pretty much the bleeding edge of my knowledge so I would be interested in hearing views on this approach and if I am missing anything major. So far I have had much success with using this approach, I find it keeps things simple as well as providing chances to scale the application further in the future. You do end up with a lot of Commands, though this does help when creating API's as everything is very discrete, also you can do nice things like queuing commands offline and applying them later which is handy for occasionally connected clients.

Thats all for now, enjoy!

ZF Storefront Example on Google Code

svn checkout http://zendframeworkstorefront.googlecode.com/svn/trunk/ zendframeworkstorefront-read-only

Enjoy...

Dependency injection (the problem)

Dependency Injection is a design pattern that deals with object configuration or object dependencies. By a dependency we mean that an Object uses another Object or Service, this brings us to the problem of how an Object handles it supporting services. The easiest way to look at this is through an example, consider the following class.

In class Foo we need to use the supporting database connection, to do this we instantiate a new dbConnection class in Foo’s constructor. This seems like a totally reasonable way to give our class access to the database connection, however by doing this we are giving Foo control over its own configuration (dependencies); this causes us the following problems.

• We cannot replace the database dbConnection instance when testing as we have no control over its instantiation.
• Foo must know how to configure the database connection which breaks the encapsulation of our object.
• We cannot easily change the dependencies of Foo, to do so we must edit the code.

So basically when we have a new call within our class we create a tight coupling between our objects. To solve this problem we need to configure the object from the outside rather than from within, we can do this using Dependency Injection which injects the dependencies into the object and takes control over the objects dependencies.

Types of dependency injection

To start we will look at some basic types of Dependency Injection, we can easily use these techniques in any application without the need for a Dependency Injection framework, though we still use these techniques even with a framework.

Constructor based injection

Constructor injection is where we inject our dependencies via the objects constructor method; if we now go back to the Foo example we can refactor that class to support constructor injection.

We can see that we have only had to make minor changes to the class to implement constructor injection. To do this we now pass the dbConnection class into Foo via a constructor parameter, meaning to use Foo we now do:

The dbConnection class is now injected into Foo, meaning we can easily replace it and have removed the responsibility of instantiation from Foo.

As we can see this is very simple and I am sure we have all already done similar things in our code but maybe without knowing. We can also further improve this by introducing an interface, currently the constructor parameter is type hinted as dbConnection meaning we can only pass in instances of dbConnection or subclasses of it.

By introducing an interface for dbConnection we can now easily create many different types of dbConnection that Foo can use, Foo will know how to use each connection type as they will all share the same public interface. Generally this is good practice when injecting dependencies as it make our implementation much more flexible.

Setter based injection

Setter based injection is just as simple as constructor based injection, however this time rather than providing our dependencies in the construct we provide them using a setter method.

Going back to our example we can refactor Foo to use setter injection.

We can see this is a fairly simple refactoring of Foo, this time we can inject our dependency via the setter and retrieve it via its getter. So which type of injection is best? Well really both are valid, using constructor based injection you can be certain that your dependency will not be forgotten to be injected as they are required to instantiate the object, with setter based injection you could forget to inject your dependency. However, with setter based injection you can get around this using Lazy Injection, which we will look at next.

Lazy injection

When using setter based injection we could possibly forget to inject a dependency, also if we have a large amount of dependencies our code could look like this:

An awful lot to remember when instantiating an object, also we are lazy programmers so we never want to type this much!

Here we have simply added an if statement into the getter method for the database connection and if the _db property has not already been set we instantiate a new default dbConnection object. This affectively lazy loads our dependency for us if we have not already set one. By no means is this a perfect solution to our problem, what if we need to configure the dependent class too? Well, we then get horrible situations where we have configuration code with our classes or code that fetches the configuration or we go for more lazy configuration and so forth. So this is not perfect but at least it does solve some of our problems, this is why you will notice that I use it a lot in the Storefront application!

Unified Constructor

Another important technique to note is the Unified Constuctor, this is used in many ZF components already and provides a powerful way to configure an object. Whilst this is not strictly Dependency Injection we should be aware of it as it can be used in conjunction with Lazy Injection to good affect.

The idea of a unified Constuctor is to allow options/config to be passed into the constructor of the object that requires configuration, this then creates a construct that looks the same for many objects giving us the unified name.

To fully explain lets look at an example.

So here we can see that Foo now accepts $options in its construct, $options will be either and array or Zend_Config instance that contains the objects configuration. The setOptions() method is called from the construct and simply iterates over the $options array and calls the setters that match the keys in that array. This means that along with the Lazy Injection we can now override the default database connection using the unified construct.

This again lets us configure our objects from outside and breaks up those tight dependencies, there are some obvious drawbacks to the unified construct mainly that intellisense does not work and the code is not as clear as it could be as you need to know what the options are, though they do match the setters anyway.

Dependency Injection Containers

At this point I was going to show how we can use the Yadif DI Container to move all object configuration outside of our objects, however as I mentioned earlier after some discussion and research I now believe that the use of a DI container in PHP may be overkill in most situations.

So what does a DI Container look like?

The $config variable would contain a set a configuration instructions that tells the container how various object or components should be instantiated and configured. Therefore, we would retrieve all new objects via the container and would never use new to instantiate our objects, pushing all instantiation and wiring to the container.

So whats the problem? This does look like a very reasonable approach when you have many dependencies, however as PHP is a dynamic language that is generally used in a web environment we have a problem with the amount of objects that are created and potentially never used. Consider the following diagram.

If we were to retrieve A from the DI Container the Container would automatically instantiate six other objects, these in turn could create other objects and so on. This in PHP can become impractical as generally we are running in a stateless environment and many of these objects may never be used and take up memory. In Java this approach does not matter so much as it is stateful and eventually the objects will be used.

With this in mind I would only use a DI Container if you are running PHP in some sort of stateful environment. For now I would suggest using a combination of Lazy Injection, Unified Constructor and Factories to wire you objects, though a small DI Container used carefully can still be helpful.

Conclusion

A big part of Dependency Injection is helping us to create testable code, all the manual DI techniques I have covered here help to create a testable codebase even without the use of a DI Container. Remember the biggest killers for testable code are:

• Global State
• new calls within your code
• Singletons (these are global state)
• Static calls (global state again...)
• PHP Function calls (global state yet again...)

So to sum up, Dependency Injection techniques are very valuable in our day-to-day programming, enabling us to create easy to test code. DI Containers probably should be used only with great care in PHP.

Footnote 1: If you are interested in Yadif or want to see a DI Container in action I have released code for the Storefront which I used in my experiments. Google Code - Yadif & Storefront

Footnote 2: Remember we can use Lazy Injection to guard against all the bad things for testability not just new calls.

Footnote 3: To guard against PHP core function cores which are in the Global Scope we can make a proxy class.

By creating a class that proxies to the global PHP functions we can now cleany replace calls to them within our classes during testing.

The Problem

Ok so the problem is that a Domain Object has a dependency on another Domain Object (Not one produced by Zend_Entity, those dependencies are already handled) or Service, Zend_Entity should not know about the Dependencies as it is not a DI Container. So how can we get these dependencies into the Domain Object?

Why Solve it?

Well if we can not have other dependencies to our Domain Objects we are going to end up using our Domain Objects like simple DAO's which they are not, this will walk us into the Anemic Domain Model

Example Domain Object

We can see that our Domain Object needs to use the Mail Service, so we need to fulfill this dependency.

A possible solution

Ok here's my prototype :)

Changes to Yadif

I am using Yadif (http://github.com/beberlei/yadif) for Dependency Injection, but I need to add the ability to inject into an already created instance.

So this is a very rough addition to Yadif and simply uses the current container implementation to inject dependents via setters, obviously construct injection is out of the question here.

Zend_Entity Event

Next we need to add a new event into Zend_Entity.

This class is then registered to Zend_Entity and postLoad is called every time an entity is created.

Here we get the container from the bootsrap and then use the new inject method to populate the entities dependencies. This is a pretty lazy way to do this, it's probably better to inject the container.

Example Object Wiring

So here we have our object wiring where we setup the dependencies.

Example usage

Finally here is an example usage:

Conclusion

Well this has been a very quick blog post but I hope these notes either spark debate or help someone, any suggestions are welcome.

I am still working on my Dependency Injection article, hopefully have that done soon ish and hopefully i will get some time to cover more on Zend_Entity...

Now that I have more free time I will hopefully be posting some follow on articles here, these will continue on from the end of the book looking at new Zend Framework features and build upon the Storefront example application.

The first article planned on my whiteboard is Dependency Injection using the Yadif DI Container, this will hopefully be done in a month or so (I am taking it easy for a while) :)

Thanks to everyone who helped!

I would like to thank all the people who have supported me during a very long year of writing this book, especially my wife who has been very patient with me, without her support none of this would have been possible, I love you very much.

It has been a very long road and I hope everyone enjoys the book!

Thanks for any help :)

How exciting, I should have the final chapter finished this weekend, then its just cleaning everything up and we are good to go!