MVC -Anwendung. Wie passt mehrstufige Architektur?

Question

Ich bin neu im Konzept von MVC und mehrstufiger Webarchitektur. Ich entwickle eine PHP -Anwendung und verwende eines der verfügbaren MVC -Frameworks. Meine Frage ist wie folgt:

Soweit ich weiß, wird MVC an und für sich nicht als mehrstufige Architektur angesehen. Ich kann verstehen, dass die Verwendung von MVC allein einen Schritt nach einem unstrukturierten Ansatz ist, aber ich überlegte, wie eine einfache 3-stufige Architektur passen würde? Würde sich MVC in der Präsentationsschicht befinden? Was sind die Vorzüge, einen abgestuften Ansatz hinzuzufügen? Nach dem, was ich sammelte, gibt es allein mit MVC keine explizite Datenobjekte, die für das Abrufen von Daten aus der Datenbank verantwortlich sind, und dies wird normalerweise in das Modell gefüllt. Ebenso kann die Geschäftslogik, die in einer dreistufigen Architektur in einem „Geschäftslust“ (oder wie auch immer Sie es nennen möchten) in den Controller eingetaucht werden können.

Ist mein Verständnis etwas richtig? Ich weiß, dass ich viele Fragen gestellt habe, aber ich würde gerne hören, wie Sie eine N-Tier-Architektur in Ihr MVC-Framework (PHP oder auf andere Weise) integriert haben, da ich davon ausgehe, dass die beiden sich nicht gegenseitig ausschließen. Vielen Dank!

Answer 1

M) m ist dein Modell. Dies lebt im Allgemeinen in Ihrer Geschäftsebene oder in der Ebene direkt hinter Ihrer Präsentationsschicht. Viele Menschen mögen jedoch nicht, dass die Präsentationsschicht über die Geschäftsschicht kennt, und so werden sie weiter abstrahieren, indem sie sogenanntes ViewModel haben. Diese sind häufig DTO (Datenübertragungsobjekte), die Ihr Domänenmodell locker zuordnen. Für mich (.NET Guy) gibt es Tools wie Automapper, um die Konvertierung vom Domänenmodell zum Anzeigen des Modells vorzunehmen.

V) V ist deine Ansicht. Die Ansicht ist Ihre Präsentationsebene. Dies ist der tatsächliche HTML- oder PHP -Code, mit dem der Benutzer direkt berührt und interagiert. Die Ansicht sollte so leicht wie möglich sein (dh wenn möglich keine Logik). Versuchen Sie, irgendeine Art von If/dann Szenarien aus der Ansicht zu fassen und bleiben Sie nur beim Anzeigen und Sammeln von Daten. Präsentieren Sie Ihren Webdesignern ein ViewModel, damit sie Ihr Domainmodel nicht kontaminieren.

C) C ist Ihr Controller. Das ist wie ein Koordinator. Sie werden Daten aus Ihrer Ansicht entnommen und stellt sicher, dass sie zur Verarbeitung dieser Daten zur Funktion/zur Verarbeitung dieser Daten rechnen. Es koordiniert auch Daten vom hinteren Ende auf dem Weg zum Frontend.

Wo mehrstufige Designkonzepte eingehen, befindet sich hinter der Präsentationsschicht (wo sich MVC hauptsächlich befindet). Wenn der Controller Daten aus der Ansicht entnimmt und sie wieder an das hintere Ende weitergibt (wenn Sie DDD oder Domänenentwurf befolgen), übergeben Sie die Daten an einen Anwendungsdienst (eine Klasse, die das Back-End-Abschluss koordiniert). Der Dienst könnte die Daten weiter in eine Repository -Ebene bringen (eine Klasse, die sich mit der Datenbank, dem Dateisystem, Webdiensten usw. ausspricht - alle Infrastrukturmaterial). DDD ist ein großes Thema, wird aber Ihren Kopf durch den N-Tier-Ansatz und wie es mit MVC funktioniert.

Bei der Erforschung dieses Themas schauen Sie sich IOC (Inversion der Kontrolle), DI (Abhängigkeitsinjektion), TDD (Test -Driven -Entwicklung) und möglichst viele Muster wie möglich (Fassade, Fabrik usw.) an.

Answer 2

Im Allgemeinen sollte die Geschäftslogik nicht im Controller enthalten sein - Sie würden massive Controller haben, wenn Sie diesem Muster befolgt werden. Das Modell beherbergt im Grunde genommen alle Ihre Nicht-Presentationsschichten ... Datenzugriffs-, Geschäftslogik- und Geschäftseinheitobjekte. Ihr Controller bereitet die Geschäftsdaten für die Ansicht vor.