In response to some of the comments made on his previous post about why you should use dependency injection in your applications, Charles Sprayberry is back with some more concrete examples showing how it all works with some code to back it up.

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.

In a recent post Marcelo Gornstein takes a look at using dependency injection with Doctrine2 using his Ding container.

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.

In this recent post from Charles Sprayberry he explains why using dependency injection (DI) in your application is a good idea and can help make things easier in the long run.

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

In this final post of his series about building a framework on Symfony2 components, Fabien Potencier focuses again on flexibility - allowing you to have more than one front controller with different configurations thanks to dependency injections.

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.

Michael Nitschinger has a new post to his blog looking at using the popular Composer tool for package management together with Lithium to make dependency management simpler.

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).

On the Nelm.io blog today there's a new post (part one of a series) about using Composer and Packagist to manage PHP applications as packages.

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.

DevShed has posted a series of tutorials talking about different sorts of service layers in PHP applications - seven of them to be exact:

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

In a new post to his blog Padraic Brady takes a look at dependency injection in Zend Framework 2.0. In this first part, however, he introduces the concept of "dependency injection" and offers a few suggestions on its use and tools that can make it simpler.

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.

Wojciech Sznapka has a new tutorial posted to his blog today looking at removing some of the issues surrounding dependencies in PHP applications with the help of closures.

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.

In his latest post to his Web Species blog Juozas Kaziukenas looks at dependency management in PHP applications and offers a few suggestions of how you can make them easier to track.

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.