A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.

One of those was, evidently, quite controversial: in v3, zend-servicemanager no longer defines the ServiceLocatorAwareInterface, and this particular release of zend-mvc raises deprecation notices when you attempt to inject a service locator into application services, or pull a service locator within your controllers.

The arguments go something like this:

• "Dependency injection is too hard to understand!"
• "This feature simplifies development!"
• "If this is so bad, why was it in there in the first place?"

These are usually followed by folks:

• saying they'll switch frameworks (okay, I guess?);
• asking for re-instatement of the feature (um, no);
• asking for removal of the deprecation notices (why? so you can delay your pain until upgrading, when you'll ask for re-instatement of the feature?); or
• asking for a justification of the change.

So, I've decided to do the last, justify the change, which addresses the reasons why we won't do the middle two, and addresses why the assumptions and assertions about ServiceLocatorAware's usefulness are mostly misguided.

Here's the scenario: you have code that will emit headers and content, for instance, a front controller. How do you test this?

The answer is remarkably simple, but non-obvious: namespaces.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return.

I agree with a ton of it — heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently.

Controllers — Actions in ADR — can be explained as facades.