Entitäten und Dienste als Grundlage verteilter Logik für das MVC-Entwurfsmuster

Bei der Entwicklung von Anwendungen unterschiedlicher Größenordnung wird es immer interessanter, unterschiedliche Ansätze zum Entwerfen einer Webanwendung anzuwenden. In jüngster Zeit ist das Problem der Trennung von Logik in einem großen Projekt basierend auf dem MVC-Entwurfsmuster besonders akut geworden.

Unternehmen und Dienstleistungen

Entitäten

Da die Aufgaben komplexer und komplexer geworden sind und es unmöglich ist, alle Daten in der Datenbank zu speichern, wurde beschlossen, statische Datenentitäten im Projekt zu erstellen. Das Wesentliche ist einfach: Grundlegende statische Daten werden an einem bestimmten Ort gespeichert, der in PHP-Code verarbeitet werden kann, und ihre englischsprachige Darstellung wird in die Datenbank eingegeben.



In einer einfachen Ansicht könnte die Entity.php- Klasse folgendermaßen aussehen:

declare(strict_types = 1);

namespace entities;

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

Seine Erben müssen die Eigenschaft $ map implementieren, die sie wie folgt erhalten:

E1::getMap();

Darüber hinaus erfüllen die meisten statischen Daten die Empfangslogik. Wenn Sie Daten gruppieren oder zusätzliche Daten auswählen müssen, ist diese Logik bereits in den geerbten Klassen implementiert.

Dienstleistungen

Services dienen zum Speichern der Geschäftslogik der Anwendung. Darüber hinaus können Dienste als vom Framework getrennte Logik verwendet werden. Ein Service ist eine Sammlung von Methoden, die die Logik einer Anwendung implementieren. Bedingungen, die für den Dienst definiert wurden:

• Der Dienst sollte nicht unabhängig auf Controller und Ansichten zugreifen.
• Der Dienst kann auf Datenbanken, Modelle und Entitäten zugreifen.

Im besten Fall muss der Controller alle erforderlichen Daten an den Dienst senden. Es kann jedoch vorkommen, dass er sich unabhängig auf ein Modell beziehen muss, um die Daten zu empfangen. Daran ist nichts auszusetzen, aber es ist besser, sich an die Logik zu halten, dass der Controller Datenrouten betreibt.



Standardmäßig implementiert der Dienst keine Standardlogik, da es sich um eine eindeutige Ausführung eines Teils des Projekts handelt. Daher wurde entschieden, dass die Basisdienstklasse nicht erstellt wird. Es ist jedoch zu beachten, dass es besser ist, Basisklassen zu erstellen, auch wenn diese leer sind. Dies liegt an der Tatsache, dass ein Moment kommen kann, in dem alle Erben dieselbe Logik haben oder eine Methode ausführen müssen. Um nicht in allen Klassen Änderungen an der Vererbung vorzunehmen, ist es einfacher, zunächst von der Basisklasse zu erben, in der diese Situation in Bezug auf temporäre Ressourcen viel weniger schwierig und billiger ist.



Im Allgemeinen kann der Datenfluss in der vorgeschlagenen Architektur wie folgt dargestellt werden:

1. Die Daten oder Anforderungen gehen an die Steuerung.
2. Der Controller kommuniziert bidirektional mit dem Modell, dem Service und der Entität. Hier erhält und gibt er einige Daten zurück.
3. Der Dienst sendet Daten an die Steuerung, empfängt oder sendet Daten an das Modell.
4. Die Steuerung sendet die empfangenen Daten an die Ansicht.

Somit stellt sich heraus, dass die Daten und das Prinzip der Anwendung zwischen den grundlegenden MVC-Elementen und den neuen verteilt sind.

Fazit

Es ist anzumerken, dass die Einführung dieses Ansatzes es ermöglichte, die Entwicklung von Anwendungen erheblich zu vereinfachen und den Datenfluss zu steuern. Die meisten Daten wurden aus der Datenbank entnommen, wodurch die Größe verringert und die Gesamtgeschwindigkeit der Anwendung erhöht wurde, indem die Anzahl der Anforderungen verringert wurde.