Entities and services as the basis of distributed logic for the MVC design pattern

When developing applications of different scales, it becomes more and more interesting to apply different approaches to designing a web application. Recently, the issue of the separation of logic in a large project based on the MVC design pattern has become especially acute.

Entities and services

Entities

Since the tasks have become more complex and complex, and it is impossible to store all data in the database, it was decided to create static data entities in the project. The essence is simple - basic static data is stored in a certain place, which can be operated in PHP code, and their English-language representation is entered into the database.



In a basic view, the Entity.php class might look like this:

declare(strict_types = 1);

namespace entities;

class Entity {
	protected static $map;
	
	public static function getMap():array {
		return static::$map;
	}
}

Its heirs must implement the $ map property, which they will receive as follows:

E1::getMap();

Moreover, most of the static data will satisfy the logic of receiving. If you need to group data or select additional data, then this logic is implemented already in the inherited classes.

Services

Services are designed to store the business logic of the application. In addition, services can be used as logic separate from the framework. A service is a collection of methods that implements the logic of an application. Conditions that were defined for the service:

• the service should not independently access controllers and views;
• service can access database, models and entities.

In the best case, the controller must transmit all the necessary data to the service, but a situation may arise that it will need to independently refer to some model to get the data. There is nothing wrong with that, but it is better to adhere to the logic that the controller operates data routes.



By default, the service does not implement any standard logic, since it is a unique execution of a part of the project. Therefore, it was decided that the base service class would not be created. It should be noted, though, that it is better to create base classes even if they are empty. This is due to the fact that a moment may come when all heirs will need to have the same logic or execute some method. In order not to make changes in inheritance in all classes, it is easier to initially inherit from the base class, in which this situation is much less complicated and cheaper in terms of temporary resources.



In general terms, the data flow in the proposed architecture can be represented as follows:

1. The data or request goes to the controller.
2. The controller communicates with the model, service and entity in a bidirectional manner. Here he receives and gives back some data.
3. The service sends data to the controller, receives or sends data to the model.
4. The controller sends the received data to the view.

Thus, it turns out that the data and the principle of operation of the application are distributed between the basic MVC elements and the new ones.

Conclusion

It is worth noting that the introduction of this approach has greatly simplified the development of applications and control the flow of data. Most of the data was taken out of the database, which reduced its size and increased the overall speed of the application by reducing the number of requests.