Wie sollte ein Modell in MVC strukturiert sein?

In MVC repräsentiert das Modell die Geschäftslogik und Daten der Anwendung. Es kapselt domänenspezifische Logik und Regeln und ermöglicht es der Anwendung, Aufgaben auszuführen und Entscheidungen zu treffen, ohne auf die Benutzeroberfläche oder den Controller angewiesen zu sein.

Modellkonzept:

• Ein Modell ist keine Klasse oder kein Objekt. Es handelt sich um eine Ebene, die aus drei Hauptelementen besteht:

  • Domänenobjekte: Repräsentieren Geschäftseinheiten und enthalten spezifische Logik für die Problemdomäne.
  • Datenzuordnungen: Behandeln die Datenpersistenz und die Interaktion mit externem Speicher B. Datenbanken.
  • Dienste: Orchestrieren Sie Interaktionen zwischen Domänenobjekten und Datenzuordnungen und stellen Sie eine Schnittstelle auf höherer Ebene für die Interaktion mit dem Unternehmen bereit Logik.

Separation of Concerns:

• Die Modellebene ist von der UI-Ebene (Ansicht und Controller) getrennt. .
• Die Kommunikation mit dem Modell erfolgt ausschließlich über Dienste, wodurch eine klare Trennung der Anliegen gewährleistet und ein Durchsickern der Domänenlogik in die Benutzeroberfläche oder den Controller verhindert wird Code.
• Diese Trennung fördert das Single-Responsibility-Prinzip (SRP), Flexibilität und einfachere Testbarkeit.

Zugriff auf das Modell:

• In Ansichten und Controllern können Sie über Abhängigkeitsinjektion mithilfe von Frameworks wie dem DI-Container von Symfony oder auf Modelldienste zugreifen Auryn.
• Dienste können in Konstruktoren injiziert oder über eine Fabrik aufgerufen werden.
• Dieser Ansatz stellt sicher, dass alle notwendigen Dienste für diese Komponenten verfügbar sind.

Modellstatus ändern:

• Controller sind für die Verarbeitung von Benutzereingaben und die Änderung des Modells verantwortlich Zustand.
• Sie rufen Dienstmethoden auf, die wiederum mit Domänenobjekten und Datenzuordnungen interagieren, um notwendige logische Operationen durchzuführen.

Datenpersistenz:

• Domänenobjekte stellen Geschäftseinheiten dar, sind sich jedoch der Speicherung nicht bewusst.
• Data Mapper kümmern sich um die Datenpersistenz und den Abruf von Daten externer Speicher.
• Diese Trennung ermöglicht es der Geschäftslogik, unabhängig von der spezifischen verwendeten Speichertechnologie zu bleiben.

Vorteile der Trennung:

• Erzwingt SRP, indem jeder Ebene klare Verantwortlichkeiten zugewiesen werden.
• Verbessert die Lesbarkeit und Testbarkeit des Codes durch die Isolierung des Geschäfts Logik.
• Bietet Flexibilität bei der Änderung der Geschäftslogik oder Datenspeicherung ohne Auswirkungen auf andere Komponenten.
• Vereinfacht die Entwicklung externer APIs durch Bereitstellung einer konsistenten Schnittstelle für den Zugriff auf Modelldienste.

Zusätzliche Kommentare:

• Datenbanktabellen werden nicht immer direkt Domänenobjekten und -daten zugeordnet Mapper.
• Ansichten sind keine Vorlagen, sondern verwalten die Präsentationslogik und die Vorlagenauswahl.
• Es sollte eine 1:1-Beziehung zwischen Ansichten und Controllern für jede Seite oder jeden Bildschirm bestehen.