In the opening of the movie X-Men (2000), Professor Xavier says that mutation is the key to our evolution. He adds that mutation is how we have evolved from single-celled organisms into the dominant species on the planet. Software is like a living organism. It needs to evolve in order to survive. Sometimes it needs to change a lot and it seems like a mutation. The need for change requires that software allows changes. A hard-to-change piece of software is a candidate for extinction.
Evolution for a piece of software might look like replacing one component with another. A replacement may be necessary for the maintenance or improvement of scalability, performance, or security. But if it is hard or almost impossible to replace a component of a piece of software, the improvements will have to be made in a difficult way, usually by rewriting the existing code.
Patterns help with the replacement of components as components share the same patterns. If each development team of a company creates software using different patterns for components, it will be difficult to share components, prohibiting reuse, which is a desirable characteristic for software made to last.
My introduction to Zend Framework
In 2005, I joined a large IT company with several software development units. This company developed government software and had thousands of projects in various programming languages. The problem was that each team used different standards for their projects, so component reuse was virtually non-existent. In addition, there was a history of decisions made in the past by tools with low initial coding that in the long run precipitated technology lock-in. Several teams used frameworks, but each one of them used different frameworks for the same language. So, the difficulty in sharing components remained.
In 2007, I was working for a division that was prospecting for new technologies and my team had to choose a framework to standardize PHP application development in the company. By coincidence, that year a seminar on PHP frameworks took place in the city of São Paulo. We went to this event and attended three talks, each about a framework: CakePHP, Symfony, and Zend. I already knew CakePHP from the first PHP Conference Brazil and several colleagues from my company already used Symfony. Zend Framework, however, was a complete novelty for me. This should not be a surprise because the first stable version of Zend Framework was released that year. But it had been in development since 2005.
The audience reaction to the CakePHP and Symfony lectures was similar. When the speakers executed the commands in the terminal that generated code, the audience said, Wow! But in Zend’s talk, when they saw that there was no code generator, they were disheartened. The speaker listened to the complaints and replied that although Zend did not have code generation tools, it was quite flexible, not imposing too much. Helpfully, one of the spectators noted that the framework architecture seemed to be concerned with maintaining the application and not just creating it.
On the way out of the event, I heard several people saying that they would use CakePHP or Symfony, emphasizing the code generation tools. These people probably did not have in-depth experience in software development, or rather in maintaining existing software. There are other tools that help with code generation, such as integrated development environments. Frameworks are reusable and are tools for reusing code, not new code creation tools.
One of the speakers was selling a book with an analysis of five frameworks, including the three presented at that event. I bought it, read it, and conducted tests for those frameworks, implementing the same application with each one of them. Among the five frameworks analyzed, the one that had the best characteristics of minimal complexity, loose coupling, extensibility, and reusability was Zend Framework. It was largely configurable and did not prevent the use of components from other frameworks. At the time, the PHP Framework Interoperability Group (PHP-FIG) did not yet exist, but we needed tools that offered interoperability.
PHP Framework Interoperability Group
In 2009, at PHP Conference Brazil, some PHP speakers gave a lecture called PHP Framewarks. It was a joking reference to a “war of frameworks.” Each one of the speakers defended their favorite framework and attacked the others. Maybe there was not exactly a war of frameworks, but the fact was that once you adopted a framework, it was difficult to use the components of others because each one followed its own patterns. This scenario began to change in the same year, 2009, when a group of PHP experts met in Chicago, USA, for establishing specifications of components for the PHP community. This group was first called PHP Standards Group. The first specification was about an autoloading standard – what helps the emergence of Composer. In 2011, the group changed its name to PHP Framework Interoperability Group (PHP-FIG). Since then, members of awesome PHP projects have met to discuss and write specifications called PHP Standard Recommendations (PSRs). Several frameworks and other PHP applications have adopted the specifications of PHP-FIG.
Zend Framework – the reference architecture for PHP applications
Zend Framework allowed us to create a reference architecture for PHP applications that helped applications to evolve. An application can use internal components, which are within its structure and serve only it, or make use of reusable components, which are shared by several applications. A component can perform a task that extrapolates the responsibilities of the reference architecture pattern implementations or even replace the implementation of a layer (but using the same interface).
To solve a given problem, the software architect must first look for an existing component that solves it. If it exists, but does not meet all the requirements, the possibility of extending it should be analyzed. Only as a last resort should a new component be created. In this case, the component is born as an internal component to meet a specific application. But the component architecture must be treated as generic so that it can be later published and improved so that it becomes a reusable component. Zend Framework had a structure concerned with these issues.
The first stable release of Zend Framework was released before PHP 5.3, so ZF1 did not use namespaces. There was no Composer yet, so ZF1 had its own autoload implementation. But the one aspect that Zend Framework had present in its structure was, as I mentioned, the possibility to change. In fact, the unstable versions already brought configurable code like this:
Zend_Controller_Front::run('/path/to/controllers');
Instead of determining the directory for the controller classes, Zend Framework lets the developer choose. There was a proposed project structure, and today there is a Model-View-Controller (MVC) application skeleton available to start building an application, but the possibility to change the address of the project elements remains.
Another interesting feature of Zend Framework is recognizing that PHP applications already exist and you need to evolve what already exists. There will not always be demand for new projects, but what is in production needs to be maintained. Thus, Zend Framework allows from the beginning the use of components decoupled from the MVC implementation. Being able to refactor an application using Zend Framework components meant being able to outsource tasks that weren’t the focus of the application’s business without having to change everything. Change is necessary, but if it can be done slowly, gradually, and safely, it is better.
Zend Framework evolved gradually, keeping pace with the evolution of the PHP programming language and other software development technologies while incorporating design patterns and programming paradigms. In 2008, version 1.5 of Zend Framework incorporated the Two-Step View pattern with the Zend_Layout
component and delivered a component to create dynamic forms, Zend_Form
. In the same year, version 1.6 extended PHPUnit through the Zend_Test
component. In 2009, Zend Framework gained a code generation tool, Zend_Tool
, and a component for inversion of control, Zend_Application
. IDEs such as Eclipse and Netbeans soon offered integration with Zend_Tool
.
Even in its first major version, Zend Framework started to offer, even optionally, the possibility of creating modules. Modules, in Zend Framework terminology, are self-contained units that can be reused. Module architecture is well suited to complex systems that must be divided into several subsystems. In a world of microservices, modules allow you to create an initially monolithic application that can gradually be converted into a distributed system.
You might ask, Why don’t we just create an application using microservices? The answer is another question: Is that really necessary? Today, we have elastic resources with cloud environments, but that is not a reason to allocate resources that we do not need yet. We do not need to change in advance but be prepared for change. The cake has an adequate amount of time to bake.
In version 2.0, Zend Framework evolved the module architecture and improved the consistency and performance of the components. The code was refactored to use namespaces and two new components were incorporated: EventManager
, a combination of several strategies for event-driven programming used by the MVC implementation, and ServiceManager
, a container for dependency injection. Decoupling between components has increased significantly since version 2.0.
Version 2.5 brought radical changes to Zend Framework. Each component was given its own version control repository and had an independent lifecycle. In addition, the autoloading of classes and the installation of components is now done by Composer. Until version 2.4, Zend Framework was a download everything but just use what you want framework. As of version 2.5, it became a download and use only what you want framework.
Version 3.0 of Zend Framework updated the minimum dependency on PHP to version 7, taking advantage of improvements implemented in the language. In addition, Zend Framework 3.0 brought a special microframework for creating middleware, Expressive. This microframework was implemented in strong compliance with PSRs from PHP-FIG, with complete independence from the components to be used.
And that was the end of Zend Framework. Yes, that was the end of it, because as we said at the beginning of the chapter, it is now called Laminas. Lamina means blade. The reason for this name is that the framework allows the creation of applications in layers, but thin layers, that is, with minimum necessary layer size. As Professor X said, evolution is slow. But sometimes evolution leaps forward. The change from Zend Framework to Laminas required a refactoring of all class names. In addition, the technical and social infrastructure of the community also changes. But this leap was good, because a framework with so many years of experience is more open now. And you are going to learn it here!
The differences between Zend Framework and Laminas
There are some differences between Zend Framework and Laminas as regards the community ecosystem. Zend Framework, as an open source project, accepted code contributions. Laminas, in turn, can also receive donations because it is under a non-profit organization. Zend Framework had forums and a Slack channel for the community to have discussions and make contributions. Laminas, in addition, has monthly open-to-the-public meetings and keeps a record of Technical Steering Committee votes (TSC is a group of members with technical knowledge that governs the project). In other words, Laminas is more open to community participation and transparent than Zend Framework. This is good! You can - if you wish – participate actively in the development of a product that helps you to create object-oriented web applications with several design patterns built in.
Steve McConnell states that the choice of programming language is a key construction decision for a software project. The PHP community, in turn, states that PHP is especially suited for web development. But the programming language is only one of the aspects you need to worry about when creating and maintaining web application projects. That’s why we are talking about Laminas.