Grundsätze der Aufgabenteilung in der MVC-Architektur

Ich war kürzlich für ein Projekt verantwortlich, das das MVC-Framework des Yii Framework nutzte. Zuerst dachte ich, die Struktur sei sehr robust.

Aber als wir unser Verständnis der Geschäftslogik vertieften, begannen wir uns der Ernsthaftigkeit des Problems bewusst zu werden.

Ich habe den Controller in MVC falsch verstanden und angenommen, dass die gesamte Geschäftslogik aufgrund früherer Erfahrungen in der Aktion des Controllers implementiert wurde.

Dadurch verfügt jeder Controller über Tausende von Codezeilen, die immer aufgeblähter werden.

Schließlich habe ich mich dazu entschlossen, den Code zu überarbeiten. Der Ursprung lag in der Notwendigkeit einer offenen API-Schnittstelle.

Nach der aktuellen Architektur ist es grundsätzlich unmöglich, den Code wiederzuverwenden. Ich muss viele Funktionen immer wieder schreiben, was wirklich inakzeptabel ist.

Objektorientierte Programmierung ist nicht nur ein Begriff aus Lehrbüchern!

Erst als ich mit dem Praktizieren begann, wurde mir klar, wie selten es ist, objektorientiertes Bewusstsein und eine globale Perspektive zu haben.

MVC-Designprinzipien

Was genau ist MVC

Modell- View-Controller (MVC) ist ein Design-Framework (Design-Muster).

Das Ziel von MVC besteht darin, die Geschäftslogik von Überlegungen zur Benutzeroberfläche zu trennen.

Auf diese Weise können Entwickler jeden Teil einfacher ändern, ohne die anderen zu beeinträchtigen.

In MVC stellt Model Daten und Geschäftsregeln dar; View enthält Benutzeroberflächenelemente wie Text, Formulare usw.; Controller verwaltet die Kommunikation zwischen Modellen und Ansichten.

MVC wird beispielsweise in der J2EE-Anwendungsentwicklung implementiert.

View ist ein Servlet, das jetzt im Allgemeinen mit Struts implementiert wird Eine zu implementierende Entity-Bean.

2. Auf welche Probleme bin ich gestoßen

Yii Framework ist ein beliebtes PHP-Framework, das auf dem ActiveRecord (AR)-Konzept von Ruby on Rails basiert.

Jede Tabelle in der Datenbank kann die AR-Klasse verwenden, um problemlos Hinzufügungs-, Lösch-, Änderungs- und Abfragevorgänge durchzuführen.

Es behandelt AR als Modell und empfiehlt, es in einem Verzeichnis namens „Models“ abzulegen.

Nachdem ich also automatisch die der Tabelle entsprechende AR generiert hatte, ging ich davon aus, dass ich bereits über die Modellebene verfügte.

Eigentlich ist AR nur eine DAO (Datenzugriffsschicht), keine Modellschicht.

Fast unser gesamtes Geschäft ist im Controller angesiedelt: verschiedene logische Beurteilungen der von Benutzern übermittelten Formulare durchführen, Berechnungen durchführen, AR instanziieren, um Daten zu speichern ...

Wegen eines Controllers dort Es wird mehrere Aktionen geben, und jede Aktion verfügt über eine solche Geschäftsverarbeitung.

Schließlich stellte ich fest, dass mein Controller-Code mehr als 1000 Zeilen umfasste.

Eines Tages sagte der Leiter plötzlich, dass unser System APIs für bestehende alte Systeme öffnen sollte, um Schnittstellen von Drittanbietern aufzurufen und bereitzustellen.

Der Dritte muss nur einen Parameter angeben, und dieses System gibt nur einen Ergebniswert an. Die Geschäftsverarbeitung ist ihm egal.

Das Schlimme ist, dass der Controller diese Dienste bereits implementiert hat, aber Formularübermittlungen akzeptiert. Wie kann er auch SOAP-XML-Dokumente akzeptieren?

Controller sollten wie Kondome so dünn wie möglich sein.

Seine Verantwortung sollte nur Benutzereingaben akzeptieren und diese dann sofort zur Verarbeitung an andere Klassen weiterleiten.

Auf diese Weise ist der Controller nur für die Bereitstellung verschiedener Schnittstellen verantwortlich, sodass wir die Geschäftslogik trennen können und das getrennte Geschäft problemlos wiederverwendet werden kann.

Wer kümmert sich um diesen abgetrennten Teil des Geschäfts? Die Antwort sollte Modell lauten.

3. Verantwortlichkeiten von View

Der View-Teil ist relativ klar, er ist für die Anzeige zuständig.

Alles, was nichts mit der Anzeigeoberfläche zu tun hat, sollte nicht in der Ansicht erscheinen.

Daher sollten komplexe Urteilsaussagen und komplexe Berechnungsprozesse grundsätzlich nicht in View erscheinen.

kann einfache Schleifenanweisungen und Formatierungsanweisungen enthalten. Beispielsweise ist die Textliste auf der Blog-Homepage eine Art Schleife.

Für PHP-Webanwendungen ist HTML der Hauptinhalt in View.

View sollte niemals die Schreibmethode des Modells aufrufen.

Mit anderen Worten: View liest nur Daten aus dem Modell, schreibt das Modell jedoch nicht neu.

Wir sagen also, dass Ansicht und Modell untrennbar miteinander verbunden sind.

Darüber hinaus wird auf $_GET und $_POST in View nicht direkt zugegriffen und sie sollten vom Controller an View übergeben werden.

Darüber hinaus verfügt View im Allgemeinen über keine Inhalte zur Vorbereitung der Datenverarbeitung, wie z. B. Abfragen der Datenbank usw.

Diese werden normalerweise im Controller platziert und in Form von Variablen an die Ansicht übergeben.

Mit anderen Worten, die in der Ansicht zu verwendenden Daten sind eine Variable.

4. Verantwortlichkeiten des Modells

Für das Modell ist das Speichern und Ausgeben von Informationen das Wichtigste.

Zum Beispiel muss die Post-Klasse über ein Titelattribut verfügen, das zum Speichern des Titels eines Blog-Beitrags verwendet wird, und über einen Löschvorgang verfügen. Dies sind alle Inhalte des Modells.

Daten, Verhalten und Methoden sind die Hauptinhalte von Model.

In der tatsächlichen Arbeit verfügt Model über die größte Codemenge in MVC.

Modell ist der komplexeste Teil der Logik, da hier auch die Geschäftslogik der Anwendung ausgedrückt werden muss.

Achten Sie darauf, Modell und Controller zu unterscheiden.

Das Modell verwaltet die Geschäftslogik und der Controller koordiniert lediglich die Beziehung zwischen Modell und Ansicht.

Solange es einen geschäftlichen Bezug hat, sollte es im Modell platziert werden.

Datenüberprüfung, öffentliche Konstanten und Variablen sollten alle in der Modellebene platziert werden

Mit anderen Worten, Attribute oder Methoden, die wiederverwendet werden können, sollten nach der Definition in der Modellebene platziert werden. überall verwendet.

Das Modell sollte nicht auf Anfrage-, Sitzungs- und andere Umgebungsdaten zugreifen, diese sollten vom Controller eingefügt werden.

Ein gutes Design sollte aus einem fetten Modell und einem dünnen Controller bestehen.

5. Verantwortlichkeiten des Controllers

Der Controller reagiert hauptsächlich auf Benutzeranfragen, entscheidet, welche Ansicht verwendet werden soll und welche Daten für die Anzeige vorbereitet werden müssen.

Daher sollte der Zugriffscode für die Anfrage im Controller platziert werden, z. B. $_GET, $_POST usw.

Der Controller sollte sich auf den Erhalt von Benutzeranforderungsdaten beschränken und keine Vorgänge oder Vorverarbeitungen an den Daten durchführen. Dies sollte im Modell platziert werden.

Für Datenschreibvorgänge ist es zum Abschluss erforderlich, die Methode der Model-Klasse aufzurufen.

Als Reaktion auf Benutzeranfragen wird das Rendern von Ansichten aufgerufen.

Außerdem sollte im Allgemeinen kein HTML-Code oder andere Dinge auf der Präsentationsebene vorhanden sein, dies sollte der Inhalt der Ansicht sein.

6. Aufklärung

In der offiziellen Dokumentation von Yii Framework gibt es diesen Absatz:

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

Kurz gesagt: Rich Model ist besser.

Das obige ist der detaillierte Inhalt vonGrundsätze der Aufgabenteilung in der MVC-Architektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!