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.
The Problem: Active Records and Its Violation of the SRP
The Problem: Active Records and Its Violation of the SRP
The Active Record is an architectural pattern, an approach to accessing data in a database. It was named by Martin Fowler in his 2003 book Patterns of Enterprise Application Architecture and is widely used in PHP Frameworks.
Despite the fact that it is a very necessary approach, the Active Record (AR) pattern violates the Single Responsibility Principle (SRP) because AR models:
Deal with querying and data saving.
Know too much about the other models in the system (through relationships).
Are often directly involved in the application’s business logic (because the implementation of data storage is closely linked to said business logic).
There are five primary layers that we’ll cover:
The Controller Layer
Despite the fact that it is a very necessary approach, the Active Record (AR) pattern violates the Single Responsibility Principle (SRP) because AR models:
Deal with querying and data saving.
Know too much about the other models in the system (through relationships).
Are often directly involved in the application’s business logic (because the implementation of data storage is closely linked to said business logic).
This violation of the SRP is a good tradeoff for rapid development when you need to create an application prototype as soon as possible, but it is quite harmful when the application grows into a middle or a large-scale project. “God” models and fat controllers are difficult to test and maintain, and freely using models everywhere in controllers leads to tremendous difficulties when you inevitably have to change the database structure.
The solution is simple: divide the Active Record’s responsibility into several layers and inject cross-layer dependencies. This approach will also simplify testing because it allows you to mock those layers not currently being tested.
The Solution: A Layered Structure for PHP MVC Frameworks
There are five primary layers that we’ll cover:
- The controller layer
- The service layer
- DTOs, a subset of the service layer
- View decorators, a subset of the service layer
- The repository layer
The Controller Layer
Modern MVC frameworks like Laravel and Yii take on many of the traditional controller challenges for you: Input validation and pre-filters are moved to another part of the application (In Laravel, it’s in what’s called middleware whereas, in Yii, it’s called behavior) while routing and HTTP verb rules are handled by the framework. This leaves a very narrow functionality for the programmer to code into a controller.
The essence of a controller is to get a request and deliver the results. A controller shouldn’t contain any application business logic; otherwise, it’s difficult to reuse code or change how the application communicates. If you need to create an API instead of rendering views, for example, and your controller doesn’t contain any logic, you just change the way you return your data and you’re good to go.
0 comments :
Post a Comment