NetTuts.com has a new tutorial posted that digs into the Laravel IoC (Inversion of Control) container, one of the key features of the framework making it easy to create and use objects all around your applications.

Inversion of Control, or IoC, is a technique that allows control to be inverted when compared to classical procedural code. The most prominent form of IoC is, of course, Dependency Injection, or DI. Laravel's IoC container is one of the most used Laravel features, yet is probably the least understood.

He starts with an example of basic dependency injection (constructor injection) and how this relates to the Laravel framework's IoC handling (hint: it's all IoC). He includes examples of some built-in Laravel bindings and talks about the difference between shared and non-shared bindings. He also looks at conditional binding, how dependencies are resolved and how you can define your own custom binding implementations. Other topics mentioned include tagging, rebounds, rebinding and extending. He ends the article with a look at how you can use the IoC outside of Laravel too.

Paul Jones has continued his posts about dependency injection containers versus service locators in his site with this new post that hopes to make it easier for you to tell the difference between the two.

It is easy to confuse a Dependency Injection container with a Service Locator. They are very similar to each other. The differences are subtle. Indeed, it’s even possible to use a Dependency Injection container as a Service Locator, although I think it’s difficult to use a Service Locator as a Dependency Injection container. They are both sub-patterns of a more generic pattern called Inversion of Control, and some people confuse the term Dependency Injection with the more generic term Inversion of Control.

He starts off with a few questions you can ask to see which camp the implementation belongs in, mostly revolving around how the objects are fetched. He includes some code samples to help reinforce the point, showing both a service locator and DIC. He's also done some looking around at some of the major DIC implementations and which of the two he sees them as (with a few notes explaining his thoughts).

In this new tutorial on PHPMaster.com, Alejandro Gervasio looks at the Inversion of Control methodology and how it's more than just an abstract reference to dependency injection.

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

The this recent post to his blog Reese Wilson looks at using one of the modules of the Zend Framework v2, the ServiceManager, as an inversion of control container in your app.

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.

On his ClickMagnate site Christopher Bledsoe has an interesting post looking at dependency injection (or, as he calls it "inversion of control") in PHP applications.

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