Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Toptal.com:
True Dependency Injection with Symfony Components
Jan 20, 2016 @ 10:37:39

On the Toptal.com blog there's a recent post about true dependency injection with Symfony between components in your application and only using the dependency injection container for its intended purpose.

Symfony2, a high performance PHP framework, uses Dependency Injection Container pattern where components provide a dependency injection interface for the DI-container. This allows each component to not care about other dependencies. [...] But this means DI-container can be used as a Service Locator.

[...] In this article we will try to build a Symfony2 application without implementing Service Locator pattern. We will follow one simple rule: only DI-container builder can know about DI-container.

They start off by talking about the structure of the dependency injection container and how it relates to the three main types: controller, method and property injections. He then starts in on creating the sample project and requiring only the Symfony DI, configuration and Yaml components. He then creates a ContainerBuilder class and sets up the HttpKernel functionality to pull the response from the container. He then makes a simple controller with a default action that just responds with text. With this working he updates it to pull in an input variable. He then makes updates to the application with changes to the route handing, templating (Twig), Doctrine (database) and tag handling.

tagged: dependency injection di symfony component framework router yaml container tutorial httpkernel

Link: http://www.toptal.com/symfony/true-dependency-injection-symfony-components

Alejandro Celaya:
Improve DI in PHP apps with Zend Framework plugin managers
Jan 04, 2016 @ 11:40:39

In this new post to his site Alejandro Celaya offers some advice on improving the dependency injection of your application with the help of the Zend Framework plugin managers. More specifically he talks about the AbstractPluginManager, a part of the ZendServiceManager package.

Generally it is a very bad practice to inject a service container into any object, but there are some situations where it could be even good, when certain conditions are met.

In one of the ZF2 mailing lists somebody asked which were these situations. I couldn't find the email, but the answers said that you can do it when the service container manages resources of the same type, and your object virtually depends on all of them. [...] If you have another object that needs to perform database connections, you don't want to inject all of the connection objects into it, you should rather inject the connection pool. That will reduce the number of dependencies of your object.

In this situation, the connection pool is some kind of service container, but injecting it has more benefits than disadvantages.

He shows how to use the AbstractPluginManager to achieve this goal, noting the existence of a validatePlugin method that can be used to ensure all necessary dependencies are available. He includes a real example of it in use, creating a simple "social plugin manager" that verifies that the plugin provided is either a closure or instance of FilterInterface.

tagged: dependency injection di zendframework plugin manager tutorial abstractpluginmanager

Link: http://blog.alejandrocelaya.com/2015/12/31/improve-dependency-injection-in-php-apps-with-zend-framework-plugin-managers/

Sarfraz Ahmed:
Coding to Interface
Dec 29, 2015 @ 09:27:48

On his Code in PHP site *Sarfraz Ahmed * has a post talking about coding to interfaces, how its done and why he thinks it's an essential part of any application.

One of the nicest things you can add to your programming skills is coding to interface.

One of the nicest things you can add to your programming skills is coding to interface. One of the five principles of S.O.L.I.D is Dependency inversion principle which states: [...] High-level modules should not depend on low-level modules. Both should depend on abstractions [and] abstractions should not depend on details. Details should depend on abstractions.

He elaborates on this "pretty formal definition" with an example MySQL wrapper class used in a User class, making them tightly coupled to each other. He also points out the same with a `UserController. As a solution to this tight coupling problem, he suggests using dependency injection (inversion of control) to pass in instances of the classes rather than creating them internally. This still couples them, though a bit more loosely, so he suggests using an interface for the dependency instead of a concrete class. This way any number of potential classes could be passed in and the class internally knows how to use them.

tagged: code interface dependency injection ioc solid principles objectoriented coupling

Link: http://codeinphp.github.io/post/coding-to-interface/

Rob Allen:
Using Composer with shared hosting
Dec 28, 2015 @ 09:25:44

Rob Allen has a post to his site talking about using Composer with shared hosting, showing how to use this popular tool even if you're on a shared hosting environment and don't have direct SSH or shell access.

I've seen this sentiment a few times now, so this seems like a good time to point out that you do not need SSH access to your server in order to use Composer. In fact, I don't run Composer on a live server (regardless of whether it's using shared hosting) and it's not on my list of things to do in the near future.

What you do need is a process where you handle your Composer dependencies on your own computer where you have PHP running.

He gives two possible solutions to the problem: either commit your dependencies or create some kind of build script that can execute the Composer install for you on deploy. He gives details on both of these solutions including the process for installing the dependencies with an automated FTP script (run at deploy rather than committed).

tagged: composer shared hosting ftp deploy script commit dependency

Link: https://akrabat.com/using-composer-with-shared-hosting/

Lorna Mitchell:
Relying on A Dev-Master Dependency in Composer
Dec 23, 2015 @ 10:52:51

In this post to her site Lorna Mitchell makes an interesting point about relying on libraries/packages that recommend using dev-master as the target of choice when installing via Composer. It started from a Tweet and lead to more discussion. She share some of that and more about her own thinking in this post.

If your project installation instructions recommend requiring dev-master in composer, I may need to reconsider my choice of package. [...] I got a few responses asking me to expand so I thought I would take the opportunity to write more than 140 characters on this topic.

She talks about the types of dependencies she prefers to add to her systems and how, usually, the code that lives in dev-master is not actually what's desired. It could be in any state after all - broken or correct. She points out three places where she'd see this kind of dependency as "okay" but points out that they are rarely seen in a mature project. She ends with a recommendation to users to look for dev-master entries in their own composer.json files and replace them with a release to prevent issues in the future.

tagged: devmaster composer dependency reliance version stable

Link: http://www.lornajane.net/posts/2015/relying-on-a-dev-master-dependency-in-composer

Gonzalo Ayuso:
Alternative way to inject providers in a Silex application
Oct 19, 2015 @ 11:18:10

Gonazalo Ayuso has shared a method he's found for injecting providers into Silex that replaces accessing the dependency injection container as an array. It instead replaces it and allows defining function parameters instead.

I normally use Silex when I need to build one Backend. It’s simple and straightforward to build one API endpoint using this micro framework. But there’s something that I don’t like it: The “array access” way to access to the dependency injection container. I need to remember what kind of object provides my service provider and also my IDE doesn’t help me with autocompletion. OK I can use PHPDoc comments or even create one class that inherits from SilexApplication and use Traits. Normally I’m lazy to do it. Because of that I’ve create this simple service provider to help me to do what I’m looking for. Let me explain it a little bit.

He includes examples of both the normal way you can access Silex's injection containers (the "array access" method) and contrasts this with his updated method, via a method parameter on the route closure. His service provider (complete code in the post and on github), when registered, looks for controller events and performs reflection on the closure to detect which objects need to be injected. The method is then called normally but with the extra attributes set, populating the parameters.

tagged: slex service provider alternative array access parameter method dependency injection

Link: http://gonzalo123.com/2015/10/19/alternative-way-to-inject-providers-in-a-silex-application/

Marc Morera:
Namespaces in Traits
Oct 16, 2015 @ 13:53:14

In this post to his site Marc Morera talks about traits, namespaces and how they fit together (or don't).

Some projects using PHP 5.4 are actually using Traits. If you don’t know yet what a trait is, there are some interesting links for you. [...] This post is about the usage of "use statements" in Traits.

He starts with an overall picture of what he's trying to accomplish in a contribution to an open source project (with a word of caution). He talks about how you can make traits and classes more "friendly" with a refactoring example of his initial code snippet. In the end, though, he recommends basically avoiding namespaces if possible in traits, reducing headaches that could be caused either by conflicts or missing dependencies.

tagged: traits namespace difficulty dependency interaction

Link: http://mmoreram.com/blog/2015/10/16/namespaces-in-traits/

SitePoint PHP Blog:
Can PuliPHP Re-Revolutionize PHP Package Development?
Oct 08, 2015 @ 11:17:56

In this recent post to the SitePoint PHP blog Nicola Pietroluongo looks at a newer tool in the PHP ecosystem that builds on to of the already widely popular Composer to expand packages outside of just the PHP code - Puli.

Puli is a new toolkit built on top of [Composer](https://getcomposer.org) that helps to manage and exchange resources like configuration files, images, CSS files, translation catalogs, and others. These are, you’ll agree, often difficult to maintain and share across projects.

The article starts with a brief overview of how it works and where it connects in with Composer, pulling in other dependencies as defined in a puli.json file. It then walks you through the creation of a simple package - installing the Puli CLI tool, building out the project file/folder structure and mapping resources/assets into the bundle. Finally they show how to install a demo package they've created, how the project maps in to the application and the pieces that make it up. The post ends with a look at the "resource discovery" feature Puli also includes making it easier to pull in configuration options without having to manually define them.

tagged: puli package development tutorial bundle asset dependency

Link: http://www.sitepoint.com/can-puliphp-re-revolutionize-php-package-development/

Shameer C:
Slim 3: Replacing Pimple with Aura.Di
Sep 28, 2015 @ 12:12:25

In a post to his site today Shameer C shows you how to replace Pimple in Slim 3 as an application's dependency injection container. He replaces it with the Aura.Di container, a relatively easy replacement thanks to the container interoperability efforts.

Slim framework is my go-to micro framework for all small projects because of it's simplicity and easiness to use. The new version of this cool framework is just around the corner and they have released RC-1 a few days back. [...] Slim 3 has a default DI Container that extends Pimple. [...] Though Slim uses Pimple by default, we can replace it with any DI container that implements Container Interoperability interface, which is a really great feature. The only caveat is Slim sets some of it's required services from the default container. So we should do it by ourself when we use a different library.

He starts by talking a bit about the Aura.Di container and how it's different than what Pimple has to offer. He then links to a small library that makes the bridge between Slim 3 and Aura.Di and sets up the services Slim needs to operate correctly. He then steps through the code needed to integrate this into a simple Slim application based on this skeleton. Most of the work is done in the dependencies.php file where Slim's needs are set up, configured and injected into the container.

tagged: auradi dependency injection container slim3 pimple replace tutorial

Link: http://blog.shameerc.com/2015/09/slim-3-replacing-pimple-with-auradi

ThePHP.cc:
Dependencies in Disguise
Sep 28, 2015 @ 08:48:27

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.

tagged: dependency disguise injection service locator bestpractice solid development

Link: https://thephp.cc/news/2015/09/dependencies-in-disguise