To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

Dependency Injection is just a fancy term for passing dependencies to the object needing them instead of letting the object create its own. Hopefully, you've watched this great Google Clean Code talk about dependency injection by Misko Hevery where he talks about why you should ask for things instead of looking for them. I'm gonna talk about some reasons to use DI beyond just those presented in the video.

He breaks it up into a few different sections:

• It helps in the battle against global state
• It helps your design
• It makes using the single responsibility principle easier

Does it means that we have to make a choice between flexibility, customization, ease of testing and not having to copy and paste the same code into each application front controller? As you might expect, there is a solution. We can solve all these issues and some more by using the Symfony2 dependency injection container.

The Symfony2 DIC (DependencyInjection) allows you to create a container with the objects and settings that you want and inject that into the main "Framework" class for its use. He registers most of the components he's added over the series like the UrlMatcher, RouterListener, ExceptionListener, EventDispatcher and the Framework class itself. This is all stored in a separate file(s) and can be conditionally included based on your environment. He shows how to register a custom listener, add parameters to the DIC configuration.

Composer is a command-line tool that helps you manage your application dependencies. It automatically fetches packages, resolves dependencies and is easy to configure. [...] Currently, Lithium doesn't provide Composer packages out of the box, but it's easy to write one.

He starts the post with an introduction to using Composer for those new to the tool, then moves quickly into setting up your "composer.json" file to pull in the Lithium updates from their github account. Additionally, he shows how to add a dependency for twig in the "require" section and pull it down at the same time (with dependencies).

You may have heard about Composer and Packagist lately. In short, Composer is a new package manager for PHP libraries. Quite a few people have been complaining about the lack of information, or just seemed confused as to what it was, or why the hell we would do such a thing. This is my attempt at clarifying things.

The briefly explains what the tool(s) do and shows how to set up the configuration on both sides - Composer to manage the packages and the package definition configurations (including meta about the project and any dependencies). He also answers several "why" questions about the need for a package manager, using this versus PEAR, the choice of JSON for config definition and a current status of the project.

If you're looking for an approachable guide that teaches you how to implement an easily-customizable service layer in PHP, then take a peek at this article series. In a step-by-step fashion, it walks you through the development of a sample web application, which uses a service to perform CRUD operations on a domain model composed of a few user entities.

Service layer types covered in the series are:

• Working with database entities
• Data Mappers
• Database adapters
• Handling Entity Collections
• User Services
• Dependency Injections
• Modeling Domain Objects

If you've been watching the PHP weather vane (we call it Twitter for short), you may have noticed a shift in Symfony and Zend Framework. Version 2.0 of both web application frameworks feature Dependency Injection Containers (DICs) as the primary means of creating the objects (and even Controllers) your application will use. This is an interesting shift in a programming language that often stubbornly evaded adopting DICs to any great extent.

He introduces dependency injection (DI) as a method for "injecting" objects and configurations into other interfaces without any specific kind of relation between the two. Part of several DI implementations is a container that does some of the magic object creation for you. He applies this concept to a Zend Framework structure and talks briefly about why these containers are "the devil" because they (usually) add complexity where none is needed. He points out one container library, Pimple, that gets it right in his opinion - defining object creation as closures. In the next part of the series, he'll compare the Zend Framework's DI setup against Pimple (and Symfony's) implementations.

Today I ran into a little issue: how to pass generic logger object to method? I wanted to get some verbose output from method, which I call from Command, but onc time it should log with Symfony2 OutputInterface and other time it should use monolog logger. Of course I can make some wrapper class for both of them, but it would be kind of an overkill. The Closure from PHP 5.3 came with solution.

His alternative creates a closure for his Symfony2 application that defines the logger handling in an abstract way and injects that object into his job queue manager for handling. This way the manager doesn't have to worry about handing the mailing itself, it's just deferred to the mailing object. You can find out more about this technique, dependency injection, here.

Rarely a project lives by itself, especially in the days of frameworks. Furthermore, there are a lot of great open source libraries you might want to use to save time. But all of this raises a new problem - how could we manage all those dependencies. Here are some thoughts on this problem and how you might want to solve it; without shooting yourself in a foot.

He mentions svn:externals and git's submodule as options in version control systems, PEAR for package management, Apache Maven and the deps file in the Symfony framework.