PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 18:24:39 -060030http://www.phpdeveloper.org/news/22384http://www.phpdeveloper.org/news/22384
Rob Allen has a new post today sharing an extension for Slim he's written to make working with controllers easier.

In a couple of projects that I've written using Slim Framework, I've found it beneficial to organise my code into controllers with injected dependencies; probably because that's how I'm used to working with ZF2. To make this easier, I've written an extension to the main Slim class and packaged it into rka-slim-controller which will dynamically instantiate controllers for you for each route.

His library makes it easy to define controller "paths" instead of the typical closures Slim requires to direct the request to a controller file. He gives several example routes, the code that the controller needs and shows how you can inject objects into the constructor of the controller (dependency injection).

Link: http://akrabat.com/slim-framework/routing-to-a-controller-with-slim-framework/]]>Wed, 18 Feb 2015 10:19:08 -0600http://www.phpdeveloper.org/news/22375http://www.phpdeveloper.org/news/22375
The SitePoint Web blog has a recent post with two things that are on the radar when it comes to PHP - the upcoming PHP version and the practice of dependency injection.

To change things up a bit, we're going to start bringing to you items and information from those discussions that have caught our attention. Sometimes these discussions will be useful and interesting, and sometimes they may be challenging or insightful. Either way, they're likely to bring new information to light that you haven't come across before, and will help to provide insight and perspective on topics you're interested in.

He starts with an overview of the controversy surrounding PHP 7 including its name, feature removal and links to some responses to the proposed changes. The second topic, dependency injection, how it might be evil and some of the opinions that have been expressed around it.

Link: http://www.sitepoint.com/radar-php-7-controversy-dependency-injection-troubles/]]>Tue, 17 Feb 2015 09:08:39 -0600http://www.phpdeveloper.org/news/22177http://www.phpdeveloper.org/news/22177
The Laravel News site has a post today linking to five handy resources you can use to learn about the Laravel IoC (inversion of control, dependency injection) container.

The Laravel IoC container is a powerful tool for managing class dependencies. It is widely used in Laravel and an important tool for your arsenal. The community has created several tutorials for this and here are five resources that will teach you all about it. [...] By reading these tutorials you'll be up to speed in no time on the Laravel IoC container and also improve your code by implementing it in your application.

As a "bonus" there's also a link to a video narrated by Laravel creator Taylor Otwell himself about the IoC container and its use.

Link: https://laravel-news.com/2014/12/5-resources-learn-laravel-ioc-container/]]>Fri, 02 Jan 2015 10:04:59 -0600http://www.phpdeveloper.org/news/22154http://www.phpdeveloper.org/news/22154
Robert Basic has a post today showing how you can mock hard dependencies with Mockery, a mocking library for use in unit testing. In this case, "hard" refers to work around the use of "new" creating objects in hard to test places.

One problem with unit testing legacy applications is that the code has new statements all over the place, instantiating new objects in a way that doesn't really makes it easier to test the code. Of course, the easy answer to this is "Just refactor your application!", but that's almost always easier said than done. If refactoring is an option, do it. If not, one option is to use Mockery to mock the hard dependencies.

He makes use of instance mocks to show the overloading of the service without the need for a refactor. This overrides it on a more global scale, so it could have an effect on other tests. He shows how autoloading and PHPUnit's own process isolation handling can fix tis problem (though it takes more time to run the tests this way). He includes sample code of the whole process so you can easily follow along too.

Link: http://robertbasic.com/blog/mocking-hard-dependencies-with-mockery]]>Fri, 26 Dec 2014 11:14:51 -0600http://www.phpdeveloper.org/news/22123http://www.phpdeveloper.org/news/22123
Recently the "prefer-lowest" option of Composer was mentioned in relation to testing for Symfony-based applications. In this new post to his site Matthieu Napoli shows how you can do it on any project that uses the Travis-CI continuous integration service.

Composer just got a new awesome addition thanks to Nicolas Grekas: prefer the lowest versions of your dependencies. [...] This amazing option will install the lowest versions possible for all your dependencies. What for? Tests of course!

He includes all the instructions you'll need to get your Travis build using this command line option, starting with testing it on your own system first. He shows a basic ".travis.yml" file with the configuration you'll need to provide it use the "prefer-lowest" (check out line 17). He does point out that you'll need to run a "composer self-update" first though, as Travis hasn't quite caught up with the latest Composer that includes this option.

Link: http://mnapoli.fr/test-lowest-dependencies/]]>Thu, 18 Dec 2014 10:53:58 -0600http://www.phpdeveloper.org/news/21958http://www.phpdeveloper.org/news/21958
In his latest post Matthias Noback shares a few hints on how yuo can decouple from using a service locator in your application. A service locator (much like a dependency injection container) is a centralized place for storing and creating instances of objects in your apps with a bit more structure than just random "new" calls.

"Decoupling from a service locator - shouldn't that be: don't use a service locator?" Well, not really, since there are lots of valid use cases for using a service locator. The main use case is for making things lazy-loading (yes, you can also use some kind of proxy mechanism for that, but let's assume you need something simpler).

He starts with an example dispatcher class and shows how to modify the flow so that "expensive" listeners are only created in the correct context. He also suggests a few other methods for handling the idea of dependency inversion a service locator provides: using closures/callables instead of classes and using something called a "synthetic service", one set up at runtime as synthetic and used as needed on a manual basis (like in his bundle example).

Link: http://php-and-symfony.matthiasnoback.nl/2014/11/decoupling-from-a-service-locator/]]>Wed, 12 Nov 2014 09:58:06 -0600http://www.phpdeveloper.org/news/21789http://www.phpdeveloper.org/news/21789
Matthias Noback has a new post today responding to a recent post talking about virtual packages with Composer (using "provide") and some of his own thoughts of how it relates to dependency inversion.

This is a response to Peter Petermann's article Composer and virtual packages. First, let's make this totally clear: I don't want to start an Internet war about this, I'm just pointing out some design issues that may arise from using Composer's provide option in your package's composer.json file. [...] Yes, if a user wants to run the code in your library, they need to have some class that implements [the "provides" requirement]. But no, this shouldn't be reflected in the dependencies of the library. Let me explain this by taking a look at the Dependency inversion principle.

He gives an example of using a specific package for logging (the Zend logger) and how that hard-coded dependency can be refactored out using one of two methods: either a custom interface or one described elsewhere. Getting back to "provide", he lists some reasons why he thinks that defining the interface itself in the Composer configuration is a good idea. These include:

Strictly speaking (as in, would the code compile), the code from the library itself [...] just needs the LoggerInterface (which happens to be in the psr/log package).

By depending on an implementation package, you basically undo any effort you made to depend on abstractions and not on concretions.

Some day, someone may decide to introduce another virtual package, called the-real-psr/log-implementation.

The notion of an "implementation package" is really vague. What does it mean for a package to be an implementation package.

Each of the reasons has a bit of description to go along with it. He also points out an interesting example where the package actually knows about existing virtual package, the DoctrinePHPCRBundle and its use of "jackalope" and "phpcr".

Link: http://php-and-symfony.matthiasnoback.nl/2014/10/composer-provide-and-dependency-inversion/]]>Mon, 06 Oct 2014 09:53:20 -0500http://www.phpdeveloper.org/news/21557http://www.phpdeveloper.org/news/21557
The SitePoint PHP blog has posted the results of some dependency injection container benchmarks they performed on several different DI libraries, some from a few of the major PHP frameworks.

Most frameworks and larger PHP applications utilize a Dependency Injection Container with the goal of a more maintainable codebase. However, this can have an impact on performance. As loading times matter, keeping sites fast is important as ever. Today I'm going to benchmark several PHP Dependency Injection containers to see what their relative performance is like.

The libraries in their list of those tested include PHP-DI, Zend/Di and the Aura.Di component. They compare each libraries against the others based on execution time, memory usage and the number of files required to make things work. The results of each test are shown in the graphs on the rest of the post. It's also broken up into a few different kinds of tests:

Test 1 - Create an instance of an object

Test 2 - Ignoring autoloading

Test 3 - Deep object graph

Test 4 - Fetching a Service from the container

Test 5 - Inject a service

The results are pretty consistent across all of the tests with certain libraries always performing better than others....but you'll have to read the post to find out those request. The scripts that were used to get the various results are also shared on GitHub if you'd like to take them for a spin on your own.

Link: http://www.sitepoint.com/php-dependency-injection-container-performance-benchmarks/]]>Mon, 11 Aug 2014 10:15:14 -0500http://www.phpdeveloper.org/news/21266http://www.phpdeveloper.org/news/21266
The SitePoint PHP blog has a new tutorial posted showing you how to use the Laravel dependency injection container to handle dependencies in you Laravel-based applications. Younes Rafie introduces some of the basic concepts behind dependency injection and the various types to get everyone started on the same level.

As developers, we are always trying to find new ways to write well designed and clean code by adopting new styles, using design patterns, and trying new robust frameworks. In this article we will explore the dependency injection design pattern through Laravel's IoC component and see how it can improve our design.

He includes examples of the three basic types of injection - controller, setter and interface - with brief code examples of their implementation. He goes on to talk about the "Inversion of Control" principle (part of the SOLID set of principles) and how the Laravel dependency injection container helps by binding objects and instances for later retrieval. Code examples for session storage handling (through a MySQL database) are included that are automatically resolved as the class requires them.

Link: http://www.sitepoint.com/dependency-injection-laravels-ioc]]>Thu, 05 Jun 2014 11:51:08 -0500http://www.phpdeveloper.org/news/21226http://www.phpdeveloper.org/news/21226
On the Clear Code blog today there's an article posted showing you how to manage your application with Composer, the PHP dependency manager that's taken the PHP community by storm.

Composer is a dependency management tool for PHP based projects. It allows you to declare, install, and then manage all of your dependencies in your project. Right, so you can manage the libraries that your project requires in order to work. But is that all you can really do with Composer? Definitely not! In fact, I believe this is a very small part of Composer and its possibilities. In this article, I'll try to show you how Composer can be used for performing more complex tasks in PHP based projects.

He shows how to set up a system where even the base parts of the applications become dependencies and can be built up as a part of the Composer install. He includes an example of pulling from a private version control source and the matching "composer.json" file the repository will need. He also includes the composer commands to get the install up and running as well as a warning about handling credentials as a part of the execution.