Entités et services comme base de la logique distribuée pour le modèle de conception MVC

Lors du développement d'applications à différentes échelles, il devient de plus en plus intéressant d'appliquer différentes approches pour concevoir une application Web. Récemment, la question de la séparation de la logique dans un grand projet basé sur le modèle de conception MVC est devenue particulièrement aiguë.

Entités et services

Entités

Étant donné que les tâches sont devenues plus complexes et complexes et qu'il est impossible de stocker toutes les données dans la base de données, il a été décidé de créer des entités de données statiques dans le projet. L'essence est simple: dans un certain endroit, des données statiques de base sont stockées, qui peuvent être exploitées en code PHP, et leur représentation en langue anglaise est entrée dans la base de données.



Dans une vue de base, la classe Entity.php pourrait ressembler à ceci:

declare(strict_types = 1);

namespace entities;

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

Ses héritiers doivent implémenter la propriété $ map, qu'ils recevront comme suit:

E1::getMap();

De plus, la plupart des données statiques satisferont à la logique de réception. Si vous avez besoin de regrouper des données ou de sélectionner des données supplémentaires, cette logique est déjà implémentée dans les classes héritées.

Prestations de service

Les services sont conçus pour stocker la logique métier de l'application. De plus, les services peuvent être utilisés comme une logique distincte du cadre. Un service est un ensemble de méthodes qui implémentent la logique d'une application. Conditions définies pour le service:

• le service ne doit pas accéder indépendamment aux contrôleurs et aux vues;
• le service peut accéder à la base de données, aux modèles et aux entités.

Dans le meilleur des cas, le responsable du traitement doit transmettre toutes les données nécessaires au service, mais une situation peut survenir dans laquelle il devra se référer indépendamment à un modèle pour obtenir les données. Il n'y a rien de mal à cela, mais il est préférable de respecter la logique selon laquelle le contrôleur exploite des routes de données.



Par défaut, le service n'implémente aucune logique standard, puisqu'il s'agit d'une exécution unique d'une partie du projet. Par conséquent, il a été décidé qu'aucune classe de service de base ne serait créée. Il faut cependant noter qu'il est préférable de créer des classes de base même si elles sont vides. Cela est dû au fait qu'un moment peut venir où tous les héritiers devront avoir la même logique ou exécuter une méthode. Afin de ne pas apporter de modifications dans le domaine de l'héritage dans toutes les classes, il est plus facile d'hériter initialement de la classe de base, dans laquelle cette situation est beaucoup moins compliquée et moins chère dans le domaine des ressources temporaires.



De manière générale, le flux de données dans l'architecture proposée peut être représenté comme suit:

1. Les données ou la demande sont transmises au responsable du traitement.
2. Le contrôleur communique avec le modèle, le service et l'entité de manière bidirectionnelle. Ici, il reçoit et rend quelques données.
3. Le service envoie des données au contrôleur, reçoit ou envoie des données au modèle.
4. Le contrôleur envoie les données reçues à la vue.

Ainsi, il s'avère que les données et le principe de fonctionnement de l'application sont répartis entre les éléments MVC de base et les nouveaux.

Conclusion

Il est à noter que l'introduction de cette approche a grandement simplifié le développement des applications et le contrôle du flux de données. La plupart des données ont été extraites de la base de données, ce qui a réduit sa taille et augmenté la vitesse globale de l'application en réduisant le nombre de requêtes.