Traditionally, application components have been designed to operate on and control the execution environment, an approach that delivers well to some extent. [...] Instead of making the module completely responsible for logging data to multiple endpoints, we can transfer the responsibility straight to the external environment. [...] Not surprisingly, the process of inverting these responsibilities between components and the environment is formally known as Inversion of Control (or in a more relaxed jargon, The Hollywood Principle), and its implementation can be a real boost when it comes to developing extensible, highly-decoupled program modules.

He uses a set of domain objects (Posts and Comments in a typical blog structure) and the Observer pattern to show how mixed up things might get if the application isn't carefully coded. He takes this and updates it to include a "comment notification service" that implements the SplObserver and is attached to the post to be executed on an event (in this case, the setting of a new comment).

In Zend Framework 1, it was difficult to follow best practices when it came to writing testable code. Sure, you could make testable models, but once you need those models in a controller, what do you do? Zend Framework 2 makes it much easier. In this post, I'll cover the basics of injecting a model into a controller. The main goal here is to be able to wire up and configure your application from the highest level possible. Constructor injection + inversion of control makes it easy to determine which classes are dependent on other classes.

He creates a "Building" module and a "BuildingController" inside of it. This controller takes in an instance of a "Building" model as a dependency. He also shows how to define this dependency in the "getControllerConfig" method of your module to make it work automatically. He makes the "Building" model itself with no dependencies and sets it up as an "invokable" in that same "getControllerConfig" method.

.NET and Java have some great IoC (Inversion of Control) containers but PHP hasn't gotten the same kind of dependency love (I know there are a few people who have tried to tackle this problem but I wanted something that worked with Zend Framework - my framework of choice). I also wanted the dependencies to be defined via the application.ini that Zend Framework uses... So, here's my attempt at that.

He includes both the configuration (Zend Framework based) of his dependency injection (DI) class that lists the classes each instance needs to have injected and the code for the actual DI class. The process looks at the configuration file and, if it finds something with the current class name, creates an instance of the class to inject and push it into the controller.