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!

I have been busy updating the Storefront over the weekend, which now has been optimized for the performance chapter and includes Model caching (which I hope is working....)

Anyway I will leave you with a nice little Ant Task for removing the require_once statements from the Zend library :)