In a quick post to his site Sameer Borate looks more in-depth at how MVC routers work to translate the incoming request and point it to the right code for handling.

A MVC Router class or a Dispatcher inspects the URL of an HTTP request and attempts to match individual URL components to a Controller and a method defined in that controller, passing along any arguments to the method defined.

He provides the code for a simple example, matching the path directly from $_SERVER['PATH_INFO'] to a key name in a set of routes. Routes are added to the list via an add_routes method and are only matched directly. This is the most basic version of a router with many other frameworks stacking features on top including wildcard matching, optional parameters and regular expression matching.

On the Zen of Coding site they've posted a look forward at versions of several popular frameworks coming in 2018. Their list includes Phalcon 3, Symfony 4 and Laravel 5.x.

It’s that time of the year again, when we take a look at the world of PHP MVC frameworks. We get ready for the trends of 2018 and plan our roadmaps. Also, we’ll take a quick detour to look at some seagues in the areas beyond PHP MVC.

Web development changes year over year, if not faster. MVC has been a revolutionary paradigm for modern web apps. It helped millions of developers build awesome applications and launch exciting startups.

The post includes a Google Trends chart showing the popularity of searches for various frameworks with Laravel, Symfony and CodeIgniter taking the top three spots overall. It then starts with a high level view of some of the recent changes and trends in several of the frameworks, moving into more detail for each (and some of "the rest" including CakePHP, Zend Framework and Yii. It then discusses microservices, how they relate to MVC and the continuing importance of backend functionality.

On the Zend Framework blog there's a new post in their series highlighting components of the main framework. In this new tutorial they look a the Zend-log component and how it can be used for logging in your application.

Every PHP application generates errors, warnings, and notices and throws exceptions. If we do not log this information, we lose a way to identify and solve problems at runtime. Moreover, we may need to log specific actions such as a user login and logout attempts. All such information should be filtered and stored in an efficient way.

[...] Zend Framework offers a logging component, zend-log; the library can be used as a general purpose logging system. It supports multiple log backends, formatting messages sent to the log, and filtering messages from being logged.

The tutorial then walks you through the installation of the component and some basic usage of it to write directory to the 'php://output' stream. It then shows you how to set up custom formatting on the message and a few other examples of it in use:

• logging PHP events (errors/exceptions)
• using the built-in data (level) filtering functionality
• custom processors
• working with multiple backends for storage

The post ends with a look at using the Zend-log package in either a traditional MVC application or one based more on middleware (like an Expressive application).

The Toptal.com blog has a tutorial posted by Elvira Sheina showing you how to keep a framework project "slim" and manageable in a MVC pattern using a "layered" structure. This structure adds a few extra components to the traditional MVC design to keep functionality cleaner and easier to maintain.

Fat controllers and models: an inevitable problem for most large-scale projects based on MVC frameworks such as Yii and Laravel. The primary thing that fattens controllers and models is the Active Record, a powerful and essential component of such frameworks.

She starts by talking about one of the main issues in MVC applications - "fat" controllers. In this example the controllers contain the bulk of the logic for the application making it difficult to modify and potentially reuse in other places. This is particularly bad when the Active Record pattern is used and the problem of it violating the SRP (Single Responsibility Principle of SOLID development). Instead she promotes the idea of the "layered" design using controllers, a service layer, DTOs, view decorators and a repository layer. She then shows how to implement this kind of structure and tie each of the pieces together with code examples for each piece.

The SitePoint PHP blog has a new post sharing the current state of PHP MVC frameworks in 2017. The article doesn't focus on any particular list of frameworks (though the more popular ones are used in the examples) and instead focus on the overall trends they've seen in frameworks and their use.

A simple question prompted me to sit down and write this follow up to my article from about a year ago: "Any thoughts about where things are today?"

He suggests that, while several of the major frameworks are still in active development and are seeing new features in recent versions, the front-runners are probably Laravel and Symfony. He includes trend numbers to back this up (popularity, basically) but also briefly touches on others: CakePHP, CodeIgniter and Zend Framework 2. He then breaks it down into two groups: Symfony/Laravel and "the rest". The post wraps up with a look at the rise of microservices, the "destruction of the monolith" and a more recent emphasis on scalability over just features.

The Zend Framework blog continues on its series of posts showing how to create various types of web services using various components from the framework itself. In this latest post they show you how to implement a SOAP server with zend-soap, a component specifically designed to "create, serve, and access SOAP applications, and parse and generate WSDL".

zend-soap provides a full-featured SOAP implementation. SOAP is an XML-based web protocol designed to allow describing messages, and, optionally, operations to perform. It's similar to XML-RPC, but with a few key differences: arbitrary data structures may be described [and] multiple operations may be described in a message as well.

The post goes on to talk about why they're show how to use these other service types when they primarily use REST in Apigility. It also covers some of the benefits using the module has over PHP's own SOAP handling. From there it's all about the code: first just creating the server and then populating it with the classes and functions it allows. The remainder of the post is split between two other methods for setting up the server: using it in a MVC application and as middleware in something like Zend Expressive.

In a new post to his site Paul Jones wonders out loud about why developers think MVC is an application architecture versus just a user interface pattern.

I’ve pointed out before that Model-View-Controller is a user interface pattern, not an application architecture. But why would PHP developers get the idea that MVC is an application architecture in the first place?

[...] I used to think that MVC was an application architecture. Even after reading Fowler’s POEAA and seeing that MVC was for the user interface, I figured that meant I was doing “user interface applications.” But that was not quite right; it would have been more accurate to say that I had been mixing the concerns of user interface with the underlying core application.

He suggests that the reason MVC is commonly thought of as an architecture is because of the "flow" most PHP developers follow in their learning and development practices. Starting from "page scripts" where things are all mashed together, a developer then learns about the separation of concerns and how MVC helps splitting up the application easier. Paul includes a reminder, though, that the "user interface" isn't really just the frontend parts (HTML, CSS, JS) but the HTTP request/response to and from the application.

NetTuts.com has posted the latest part of their "Programming with Yii2" series today that dives deeper into the functionality of the framework and investigates the use of MVC forms and layouts.

In Programming with Yii2: Getting Started, we set up Yii2 locally, built a Hello World application, set up a remote server, and used Github to deploy our code. This tutorial will cover some of Yii's more basic concepts related to its implementation of the MVC framework: Models, Views and Controllers. We'll also explore layouts and customization of navigation menus and Bootstrap elements.

They start with a look at the model functionality Yii2 has to offer and creates a first simple model, the "Status" model, to evaluate permission status. Next up is a simple controller, one that handles incoming status requests and either creates the record or displays the information in the model. Next is the output part of the application with examples of view handling, forms and layouts.

In response to a recent post from Anthony Ferrara about MVC Paul Jones suggests that Anthony's view that it and related structures "all pretend to be application architectures" is false.

The central mistake I think Anthony makes is near the end of this post, where he states (in talking about MVC, ADR, et al.) that “All Pretend To Be Application Architectures.” That assertion strikes me as incorrect. While it may be that developers using MVC may mistakenly think of MVC as an application architecture, the pattern description itself makes no such claim. Indeed, Fowler categorizes MVC as a “Web Presentation Pattern” and not as an “Application Architecture” per se. [...] Fowler’s categorization and description of MVC define it pretty clearly as a user interface pattern. ADR, as a refinement of MVC, is likewise a user interface pattern.

He goes on to talk more about the ADR (Action-Domain-Responder) pattern, how it's more of a user interface pattern as well and how that relates to using it for HTTP requests. He suggests that the definition from Anthony may be a bit too broad and proposes the alternative "All Are User Interface Patterns, Not Entire Application Architectures" to be a bit more specific.

Lee Blue has posted his next article in a series covering some of the real costs and considerations around using PHP for your applications. In this latest post he talks about frameworks and what kind of effect they could have on the overall profitability of your business.

Last week we talked about application shelf life an aspect of PHP development that often goes overlooked. This week let's talk about how the web development framework you use contributes to the shelf life of your app and the profitability of your web application. [...] The main goal of all web frameworks is to improve the developer's ability to get ordinary things done so we can focus on the primary goals of what we're building.

He talks about how PHP was "made for the web" and why there are so many different kinds of frameworks out there (though most are generally MVC-ish). He talks about one of the standard arguments, learning curve vs efficiency, and how it compares to the "no framework framework" ideals. He then gets into some of the dark side of using frameworks, specifically how they can shorten the shelf life of an application and how difficult migration can sometimes be. He points out the irony of large frameworks: the bigger the app/framework, the harder it can be to migrate (and cost more). He encourages sticking with smaller, lighter frameworks instead and suggests coding standards, common packages and using custom libraries only where needed to create your application.