News Archive

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

Loïc Faugeron:
Decouple from Frameworks
Oct 06, 2015 @ 09:48:23

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

tagged: decouple framework opinion commandbus refactor encapsulate


Marc Morera:
Re-thinking Event Listeners
Aug 21, 2015 @ 09:17:34

Marc Morera has posted an interesting article to his site suggesting a re-thinking of how event listeners are used in applications and libraries.

Let’s talk about Event Listeners. Do you know what an Event Listener is? Well, if you are used to working with Symfony, then you should know what is intended for. If you don’t, don’t hesitate to take a look at the Symfony documentation. This post aims to start a small discussion about how an Event Listener should look like if we really want to keep things decoupled.

The starts with a brief summary of the post (tl;dr) for those in a hurry but goes on to explain things in a bit more detail too. He starts by laying a foundation, introducing what event listeners are. He also shows how they're commonly implemented and used (in Symfony2 specifically but it applies more generally too) to trigger actions in applications. He suggests decoupling things a bit more from the flow of the action and allowing, in this case, access to both the order and the customer (on a "order created" action). He takes it one step further and decouples the sending of an email into a service and then creates an instance of this when needed in the event and not before.

tagged: event listener decouple ecommerce email order action


DigitalOcean Community Blog:
Horizontally Scaling PHP Applications: A Practical Overview
Apr 24, 2015 @ 13:06:49

On the Digital Ocean blog there's a new post with a "practical overview" of how to effectively scale PHP applications, specifically as it relates to horizontal scaling not vertical.

Shipping a website or application to production has its own challenges, but when it gets the right traction, it’s a great accomplishment. It always feels good to see the visitor numbers going up, doesn’t it? Except, of course, when your traffic increases so much that it crashes your little LAMP stack. [...] But fear not! There are ways to make your PHP application much more reliable and consistent. If the term scalability crossed your mind, you've got the right idea.

The article starts with a brief overview of what scalability is and the main difference between horizontal and vertical scaling (scaling out vs scaling up). They then get into a bit more detail about what horizontal scaling is and how it commonly works in relation to the average PHP application (complete with diagrams). They also talk about some things you can do inside your code to help make things flow a bit more smoothly including decoupling between services and user session/file consistency measures. There's also a bit at the end about load balancing but as that depends a good bit on what technology you're using and the actual load, they just provide an overview and some links to other articles and tutorials with more information.

tagged: scaling application horizontal vertical decouple consistency loadbalance


Matthias Noback:
Decoupling from a service locator
Nov 12, 2014 @ 09:58:06

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

tagged: decouple servicelocator dependency closure synthetic class tutorial


Paul Jones:
What's The Difference Between Tightly-, Loosely-, and De-Coupled ?
Oct 06, 2014 @ 10:20:30

In his latest post Paul Jones recounts a Twitter-based discussion that happened between Taylor Otwell (@taylorotwell) and others on Twitter about the different types of coupling in libraries or applications. The discussion focused around three different types and their definitions: loosely-coupled, tightly-coupled and de-coupled.

The quotes from the conversation come from Taylor, but Paul includes some of his own thoughts in response (things better expressed in more than 140 characters. He talks about some of the assumptions that were made during the discussion, the general knowledge level of "basic programming terminology" and how Paul views the definition of "decoupled".

If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. [...] The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

He talks about how one of the main goals of the packages that make up the Aura project is to be decoupled from the start and how that can help with changing requirements/dependencies down the road. He also defines what he sees as "loose" and "tight" coupling, largely defined by the packages required in the "composer.json".

tagged: decouple loose tight coupling package library definition terminology


Matthieu Napoli:
Decoupling packages
Sep 26, 2014 @ 13:42:24

In a recent post to his site Matthieu Napoli looks at some first steps you can take to help decouple packages in your application. He describes a few considerations and methods to think about as you try to break those chains.

Decoupling packages is a hard thing. There are not a lot of options, and this blog post is about how some options are better than others.

Let’s say for example that you are writing a “package”, or library, to respond to HTTP requests (that kind of package could be considered the basis for a web framework). How do you handle routing? If you write your Router package as an independent package (which is good: small and specialized packages are more reusable and maintainable), you might not want to couple the HTTP package to the Router package: you want to leave users free to choose the router of their choice. So, what are your options to make the HTTP package and the Router package decoupled from each other?

He looks at a few different approaches including focusing on event-driven programming or splitting things along "edges" and making interfaces/adapters to hook them together. He also puts an emphasis on standardizing interfaces, even those outside of your own internal to the application (think the set of PHP PSRs).

tagged: decouple package event interface adapter standardized


Matthias Noback:
Decoupling your (event) system
Aug 26, 2014 @ 11:15:17

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

tagged: decouple event manager dispatch handling symfony adapter object


Matthias Noback:
Symfony2: How to create framework independent controllers?
Jun 18, 2014 @ 09:15:16

Matthias Noback has a new post to his site today, the first part of a series, looking at making framework-independent controllers for use in a Symfony2 framework-based project.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

  • Using the framework helper methods
  • Using dependency injection (manually injecting instead)
  • Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.

tagged: framework independent controller symfony2 tutorial refactor decouple


Wojciech Sznapka:
Software developers care too much about tools
Apr 29, 2014 @ 09:17:24

In his latest post Wojciech Sznapka suggests that software developers care too much about tools and not enough about software quality and structure.

Lately I see perilous situation in software development area. There are plenty of good devs so much bounded to tools. By tools, I mean mostly frameworks. [...] First of all, we all need to admit, that quality of modern MVC framework raised a lot, comparing with state of things few years ago. [...] On the other hand, there’s huge temptation to write own frameworks, ignoring the great work of community.

He talks about more of the benefits of using a framework but instead of being dependent on it for your application, make it just another tool. He recommends quality, decoupled and well-designed code separate from the framework. Additionally, he suggests using things like domain driven design to encourage reusability and accurately modeled business needs in the code.

tagged: software tools framework decouple domainmodel opinion


Kristopher Wilson:
Decoupling the Framework
Dec 02, 2013 @ 12:19:36

Kristopher Wilson has a new post to his site talking about something that could be very difficult with an existing application (and a good starting place for a new one) - decoupling from the framework. He advocates that your application shouldn't be an extension of the framework, more so a user of it to make it potentially easy to replace.

We spend a lot of time discussing and analyzing the features and merits of several frameworks, trying very hard to make sure we find the perfect one to use for our project. Rightfully so: picking the wrong framework can lead to a slew of issues down the road in terms of maintenance and scalability. [...] We also spent a considerable amount of effort making sure that there is minimal amount of coupling within our code. Strong coupling leads to problems testing, adapting, refactoring and reusing code. What if we applied that same principal to dealing with whatever framework we're using?

He goes on to look at the "framework is not your application" concept and fleshes it out with examples of it applied to a few different topics: Controllers, Models and ORMs. He also shows how, through the use of something like Doctrine's EntityManager, you can easily abstract things out so the internals of the application can easily split the application and framework.

tagged: decouple framework controller model orm doctrine entity