The StarTutorial site has posted the next article in their series introducing various design patterns and their use in PHP. In their latest tutorial they cover the Adapter pattern, a useful pattern for putting a unified interface in front of various functionality.

[The Adapter pattern] converts the interface of a class into another interface the clients expect. Adapter lets class work together that couldn’t otherwise because of incompatible interfaces.

In their example they talk about a traveller wanting to charge their devices but being frustrated by the different plugs around the world. This is where an adapter comes in handy, providing a standard method for interaction (the input plug) with a wide range of backend tools (the plugs all around the world). They use this example and built out "plug" and "socket" classes where the adapter class acts as a go-between for the plug and receptacle.

Matthias Noback has a series of posts on his site sharing some of his thoughts around layers, ports and adapters in application architecture:

Looking back at my old blog posts, I think it's good to write down a more balanced view on application architecture than the one that speaks from some of the older posts from 2013 and 2014. Before I do, I allow myself a quick self-centered trip down memory lane.

He's posted all three parts of the series, each providing either some background on him and his previous work or principles and architecture suggestions:

• Layers, ports & adapters - Part 1, Foreword
• Layers, ports & adapters - Part 2, Layers
• Layers, ports & adapters - Part 3, Ports & Adapters

Each part includes code and/or structure suggestions to help clarify points made along the way.

In an interesting mix of "old" and "new" Rob Allen as shown in this new post to his site how to push binary data into a SQL Server database from a Zend Framework v1 application.

If you want to insert binary data into SQL Server in Zend Framework 1 then you probably used the trick of setting an array as the parameter's value with the info required by the sqlsrv driver as noted in Some notes on SQL Server blobs with sqlsrv.

[...] Working through the problem, I discovered that this is due to Zend_Db_Statement_Sqlsrv converting the $params array to references with this code. The Sqlsrv driver (v4) for PHP 7 does not like this! As Zend Framework 1 is EOL, we can't get a fix into upstream and update the new release, so we have to write our solution.

He includes the code for the "hack" that you'd normally have to do to push the binary data into the database. Zend Framework v1 is EOL (end of life) so the Zend_Db_Statement_Sqlsrv class can't be updated. Instead, he writes his own replacement, creating a new adapter specific to the application that handles the input as the SQL Server driver is expecting. He then updates the application configuration to force the new adapter to be used when the ZF1 application needs to connect to the SQL Server database.

Freek van der Herten has a new post with both a reminder and a solution to an upcoming change from the Dropbox service: the disabling of their v1 API (and a PHP package you can use to be prepared).

Last year on 28th of June Dropbox deprecated v1 of their API. On the same date this year they will turn off all v1 endpoints. If you’re using using Flysystem, Laravel or the official PHP SDK to work with Dropbox, it’s the time to update.

Last week my company released a Dropbox API client and a Flysystem Dropbox adapter that both use v2 of the dropbox API. In this blogpost I’d like to explain how to install and use these packages.

He then shows you how to update your Flysystem adapters to use this new adapter for Dropbox - basically a simple code change once the package is installed. He then moves on to updating a Laravel application, configuring it's built-in file abstraction with the new adapter via a DropboxServiceProvider. The post ends with a bit talking about the update of other types of PHP applications (not using Flysystem) that could make use of other packages to make the required updates.

The QaFoo blog has a post today about outside-in testing, two design patterns - Adapter and Facade - and how they relate.

As part of our workshops on Test-Driven Development we explain to our customers how testing from the outside-in can help find the right test-mix.

The technique puts a focus on test-driven-development, but instead of the traditional approach starts at the acceptance test level. The first test for a feature is an acceptance test and only then the feature is implemented from the outside classes first. [...] Outside-In testing leads to interfaces that are written from what is useful for the client object using them, in contrast to objects that are composed of collaborators that already exist. Because at some point we have to interact with objects that exist already, we will need three techniques to link those newly created interfaces/roles to existing code in our project

These three techniques are:

• using the adapter pattern to interface with third party code
• the facade pattern to "layer" your own code
• continuous refactoring of interfaces/implementations

In this post they focus mostly on the adapter pattern. They show how to use it in interfacing with remote systems in a Symfony application (for example) based on a remote XML file. They also include the test to verify it's functioning correctly and the PHP code to make the mocks and interfaces you'll need for the test.

In a follow up to his previous article about high performance PHP with React's help, Marc Schmidt has returned with a follow up post two years after the fact with some updates and additional information.

This is a follow up article on “Bring High Performance Into Your PHP App”, which went quiet viral with over 100k visits. This does not only show that many people still struggle with PHP and its performance, but also that people are highly interested in a solution to this kind of issues. PHP-PM could be one solution. But first things first. Over two years later since my blog post about high-performance things have changed dramatically.

[...] When I hacked together some lines of code back then in 2013 I never though that this kind of application style would ever succeed in the PHP world. [...] However, things have changed there as well.

He talks about some of the advancements that have been made since his previous post including PHP 7, improvements in PHP-FM and the HttpKernel component of the Symfony framework. Along the lines of bringing even more performance to PHP applications with React, they created an adapter to link the two. The post covers some of the currently open issues, the "good things" about it and some of the design issues to keep in mind when using it. He ends the post talking about where the PHP-PM project is now and some of the benchmarks about performance between PHP-PM and PHP-FPM.

In a recent post to his site Marc Morera discusses the topic of package dependencies in PHP applications. While a lot of the concepts and terms he use are more related to Symfony-based applications, the concepts are good and could apply anywhere.

I’m part of this group of people that consider themselves addicts to open source. [...] want to expose my personal experiences about what I learned over the time by leading an open source project, several small open source bundles and PHP libraries, and I want to do it by explaining how we should take care of our Symfony bundles or PHP component dependencies.

He starts by pointing out that he's talking about framework-agnostic packages and their dependencies here (but his own experience is, again, Symfony-centric). He talks about identifying true dependencies through both use statements and composer.json configurations. He points out that the tricky part comes when your dependencies have dependencies and conflicts that may come up because of these relationships. He also talks about another way to identify dependencies (through adapter use) and package versioning problems. He then gets into talking about Symfony bundle dependencies specifically and links to a tool that can help you map out your required packages. He ends the post with a look at development dependencies and the idea of "trust" in the open source software you use.

Kevin Schroeder has a quick post to his site showing the Magento users out there how to configure the SSL connection to their MySQL database backend.

’ve been asked a few times now if there is a way to use encrypted MySQL connections in Magento. [...] The answer, to my surprise, is that there is no way of doing it out of the box.

[...] All database configurations are stored in the local.xml file and the XML specification does not allow numbers for XML node names. So no matter how you try to slice it it looks like getting the SSL settings into the Magento adapter will not work without a code change. The Internet seems to confirm this. But that doesn’t mean that it can’t be done. So I wrote a quick Magento adapter that allows you to pass in the constant values.

He walks you through the process of getting the adapter installed, configuring MySQL to allow for the SSL connections and the configuration change to make. He includes the XML you'll need to update, including the addition of a secure_driver_options to the XML to provide the necessary SSL connection information.

In an article posted to his site Rob Allen shows you how to hook in the OAuth2 authentication for an Apigility-based application with a pre-existing database table structure that may not match the defaults Apigility is looking for.

I have a client that's writing an Apigility API that needs to talk to a database that's already in place. This also includes the users table that is to be used with Apigility's OAuth2 authentication. Getting Apigility's OAuth2 integration to talk to a specific table name is quite easy. [...] However, if you want to use different column names, that's a bit trickier as they are hardcoded in the OAuth2StoragePdo class. To get Apigility's OAuth2 components to look at the correct columns, you create your own OAuth2 Adapter. I chose to extend ZFOAuth2AdapterPdoAdapter which extends OAuth2StoragePdo and go from there.

He includes the code for this extension of the PdoAdapter (a "OAuth2Adapter" class) in the post showing the definitions of the get user, set user and check password methods the OAuth2 flow needs to match users to OAuth sessions. He also includes the code for the "OAuth2AdapterFactory" class that's used to pull the custom PDO adapter class into Apigility and, along with some configuration changes, make it available for use. Then it's just a simple matter of changing the authentication type in the Apigility UI.

The Coder on Code site has posted a new tutorial covering the Adapter design pattern in detail. They talk about what the pattern is, what it can be useful for and include some code to illustrate.

The adapter pattern also referred as the wrapper pattern, I find that wrapper is a more fitting name since it describes clearly what this pattern does; it encapsulates the functionality of a class or object into a class with a common public interfaces. [...] Adapters are one of the easiest patterns to comprehend and at the same time one of the most useful ones.

He starts with some of the basic definitions of terms involved in the pattern: client, adapter and adapteee. His example centers around a notification manager class that lets you switch types between Twitter, Email and SMS messaging. His initial code has all of the message types handled in one class method. He shows how to refactor this out to an interface and a set of child classes, each with the corresponding handling in a "sendNotification" method. These are then used by an adapter in the main class to send the given message. This simplifies the main messenger class and contributes to the overall improvement of architecture and testability of the application.