Architectural patterns, sometimes referred to as an architectural style, provide solutions to recurring problems in software architecture.
Though similar to software design patterns, they have a broader scope, addressing various issues in software engineering as opposed to simply the development of software itself.
In this chapter we will cover the following topics:
- Model-View-Controller (MVC)
- Service-oriented architecture
- Microservices
- Asynchronous queuing
- Message Queue pattern
MVC is the most common type of Architectural pattern that PHP developers encounter. Fundamentally, MVC is an Architectural pattern for implementing user interfaces.
It largely works around the following methodology:
- Model: This supplies the data to the application, whether it's from a MySQL database or any other data store.
- Controller: A Controller is essentially where the business logic is. The Controller handles whatever queries the View provides, using the Model to assist it in this behavior.
- View: The actual content that is supplied to the end-user. This commonly is an HTML template.
Business logic for one interaction isn't strictly separated from another interaction. There is no formal separation between the different classes of an application.
It is critical to consider that the MVC pattern is principally a UI pattern, so it doesn't scale well throughout an application. That said, the rendering of UIs is increasingly being done via JavaScript applications, a single page JavaScript HTML app that simply consumes a RESTful APIs.
If you're using JavaScript, you may use a framework such as Backbone.js (Model-View-Presenter), React.js, or Angular to communicate with your backend APIs, though this will of course, require a JavaScript enabled web browser, which some of us can take for granted from our users.
In the event you exist in an environment where you cannot use a JavaScript app and must instead serve rendered HTML, it often is a good idea for your MVC app to simply consume a REST API. The REST API performs all the business logic, but the rendering of markup is done in the MVC app. Although this increases complexity, it offers a greater separation of responsibilities and as a result, you don't have HTML being merged with core business logic. That said, even within this REST API you need some form of separation of concerns, you need to be able to separate, the rendering of the markup from the actual business logic.
A key element to choosing an Architectural pattern suitable for an app is whether the complexity is appropriate for the size of the app. Thus, choosing an MVC framework should also be based on the complexity of the app itself and its intended complexity later on.
Given the growth of infrastructure as code, it is possible to deploy the infrastructure of multiple web services in an entirely orchestrated fashion. Indeed, using containerization technology such as Docker, it is possible to deploy multiple architectures (such as an MVC application with a separate API service) with little overhead (no need to spin up a new server for each service).
Separation of concerns is a vital trait when developing great architectures, which includes separating UI from business logic.
When thinking in terms of an MVC pattern, it is important to remember the interactions as follows:
- The Model stores data, which is retrieved according to the query put by the Model and displayed by the View
- The View generates outputs based on changes to the Model
- The Controller sends the command to update the Model's state; it can also update the View associated to it to alter how a given Model is presented
Or, it is commonly expressed using the following diagram:
Don't use an MVC framework for the sake of using one, understand why they exist and where they can fit well into a use case. Remember that when you take on a bloated framework with lots of functionality, you are taking responsibility for maintaining the whole thing going forward.
Pulling in the components as you need them (that is, through Composer) is a far more practical approach to developing software with considerable business logic.