On the PHP.cc's site has an article that looks at dependencies in disguise based on a "workshop" one of their members, Stefan Priebsch, gave at the recent Bulgaria PHP Conference.

Yesterday I gave a presentation at the [Bulgaria PHP Conference](https://thephp.cc/dates/2015/09/bulgaria-php-conference) (a great event, by the way). Following an [ad-hoc workshop](https://twitter.com/s_bergmann/status/647732967087939584) that I gave as part of the hallway track and an entertaining hackathon, I decided it was too late to join the party and went back to the hotel with some other speakers. Checking out how the day was reflected in social media, I contributed a few more tweets to a [conversation](https://twitter.com/tim_bezhashvyly/status/647861115721003008) that had started earlier in the day ([here](https://thephp.cc/dates/2015/09/bulgaria-php-conference/solid-mvc) are the slides of my talk that people are referring to). I am writing this to clarify my point, and help everybody to understand better.

He talks about dependency injection as a best practice that's followed in libraries all over the PHP ecosystem, making it easier to work with objects and their needs. Sometimes this means using a dependency injection container and others it's just constructor/method injection. He talks about how these objects are build in factory methods and recommends making one factory but points out that this only really works when all the objects you need are known up front. However, he gives several (code) examples of places where this could be difficult and how some are using service locators to solve the problem. He points out, however, that this then expands the API of the application out way too far, opening it up to objects all across the application when there may be no need. This is where the hidden dependencies can come in, things masked behind the use of a single service locator. He recommends solving the issue with more customized locators, as in his example of routing locator used to handle dependencies for a POST HTTP request.

<p. Paul Jones has updated his "service locators vs dependency injection containers" series with another post to his site today, this time he focuses on implementation not names. He suggests that the difference in naming makes it easy to think they're very different things, so he focuses on implementation rather than just the names.

As the disucussion progressed, it became more clear to me that there really is no significant difference in how Dependency Injection containers and Service Locator containers are written. They are both Inversion of Control (IOC) containers, and are not distinguishable by their code, API, features, etc. (although some may have more or fewer features than others).

As such, the terms Dependency Injection and Service Locator appear to be interchangeable in the sense that a container is a container is a container. The difference in naming comes from how the container is used, not how the container is implemented.

He suggests that one of the main differences is where they are, either inside or outside of a non-Factory object. He circles back around to the names, though, and points out that when developers talk to one another, they need to be speaking the same language. As such, he tries to set this vocabulary for the implementations, separati

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

On Reddit's PHP section there's a discussion happening about dependency injection versus service locators in two popular PHP frameworks - Zend Framework 2 and Symfony 2 (and how they're not really DI at all).

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

The Codeception blog (a BDD testing tool) has a new post on using their Locator class to create more complex tests based on XPath or CSS selectors.

In the latest Codeception 1.1.4 new Locator class was introduced. Basically it should simplify your life in writing complex XPath or CSS locators. Right now it has minimal, yet useful functionality.

The post shows how to combine more than one item for location with either a tag, CSS-based or XPath-based selector. It also shows how to use the "tabindex" method to simulate the movement through a page using the "Tab" key. Finally, there's a quick piece of code showing how to locate an item based on the "href" value. For more information on using Codeception, check out their documentation or the project's main site.

On PHPMaster.com they've posted the first part of a series looking at something that's become a hot topic in the PHP community over the last months - dependency management and service locators.

From a programmer’s perspective, the process of designing easily consumable APIs while still keeping a decent level of decoupling between the involved classes is always a tricky trade-off, as the more expressive the dependencies are, the harder the work is that needs to be done behind the scenes for wiring up the collaborators in their proper sequence.

In this two-part series I’ll be doing a quick roundup of some of the most common methodologies that can be employed for managing class dependencies in modern application development, ranging from using service locators and injectable factories, to sinking your teeth into plain vanilla Dependency Injection, and even implementing a naive Dependency Injection Container.

He talks about the "plague of the 'new' operators" and how, through the use of an injected factory object, they could be easily replaced. Code samples are included showing the initial state and the end result, refactored to inject his "SerializerFactoryInterface" into the "FileStorage" class.

Christopher Jones has posted a script to his blog today giving an example of how you can use the Spatial functionality of Oracle in a PHP application:

Oracle Spatial is a powerful library for adding location awareness to applications. This script uses the core subset of Spatial, called Oracle Locator, which is included in all Oracle Database editions.

His example connects to the database resource and makes a few example SQL queries: one that uses the sod_nn() function built in to the Spatial package to grab the store locations close to the customers, another that finds the latitude and longitude for a customer's information and a method for querying an object collection of locations in a given area.