Nach dem Lesen habe ich die Köpfe anderer Entwickler nach dem Konzept der "fetten Modelle, mageren Controller" ausgewählt:
Die meisten Befragten verwenden, was ich als Fat Controller betrachte.
Während das Thema auf Stack Overflow aufgetaucht ist, habe ich keine gründliche Beschreibung der Methode in der Praxis gefunden.
Ich habe gerade eine alte Frage hier .
Was Sie in PHP (Vanille oder Laravel oder Symfony) sehen werden, sind immer die dünnsten Controller aller Zeiten. Dies ist etwas, das Sie bereits in Rails sehen, und die Leute beginnen auch, es (mit einigen anderen Praktiken) sechseckig zu nennen. Eine Zeile Code ist alles, was Sie in Ihrem Controller brauchen, eigentlich sagen sie, dies sollte ein Ziel für alle Ihre Methoden sein. Dies ist ein Beispiel mit, ja, ein bisschen mehr als das, aber immer noch dünn:
%Vor%Ein Controller ist eine Brücke zwischen den HTTP-Anforderungen, Ihrer Geschäftslogik und Ihrer Präsentationsebene. Daher sollte es eine Anfrage erhalten, sie an ein injiziertes Objekt senden, das es verarbeiten wird und auf die Route umleiten (oder eine Ansicht rendern), die dafür verantwortlich ist, einem Client (oder Benutzer) Feedback zu geben. Alles andere, einschließlich der Validierung, sollte in Ihren Repositories, Diensten, Modellen (MVC, yay!), Etc. geschehen.
Aber wir könnten diesen Controller auf hexagonale Weise umgestalten, um das Ziel einer Einzellinie pro Methode zu erreichen:
%Vor% Grundsätzlich verwenden Ihre Repository-Klassen den eigenen Aufrufer ( $this ), um die Methoden succeeded und failed auszulösen.
Modelle sind zu sehr mit Ihren Daten verwandt, manchmal sind sie Ihr ORM und sprechen direkt mit Ihrem Datenbankserver. In diesen Tagen werden Sie feststellen, dass Benutzer Repositories und Dienste als Ebenen zwischen ihnen verwenden.
Ein Repository ist eine Klasse, die durch direkte Kommunikation mit Ihren Modellen die Informationen verarbeitet und sammelt, die Ihre Anwendung benötigt. Ihre Anwendung sollte nicht wissen, was nötig ist, um einige Informationen in Ihrer Datenbank auszuwählen, wählen Sie aus, wo, Reihenfolge, Gruppierung, das sind Dinge, die nur Ihren Modellen bekannt sein sollten, also ist dies ein Repository:
%Vor%Alles, was nicht direkt zu Ihrer Geschäftslogik gehört, meist externe Services, die am weitesten von Ihrem Anwendungscode entfernt sind, desto besser entkoppeln Sie sie. Das Erstellen externer Pakete (Composer-Pakete) für diese Dienste ist eine gute Möglichkeit, sie von allem anderen zu entkoppeln, und wenn Sie sie als Framework-Agnostiker betrachten, haben Sie Anspruch darauf, 10 Störpunkte . In Laravel können Sie Dienste erstellen, indem Sie drei Arten von Klassen integrieren:
1) Serviceklasse (n): verantwortlich für das, was Ihr Service tun muss, all Ihre Servicelogik geht hierhin.
2) Dienstanbieter: Er ist dafür verantwortlich, Ihren Dienst hochzufahren und ihn zu Laravels IoC-Container hinzuzufügen, damit er jederzeit einsatzbereit ist. Beachten Sie jedoch, dass Laravel Ihre Dienstklassen nur dann instanziiert, wenn Ihre Anwendung sie wirklich verwendet / p>
3) Fassade: Ermöglicht den Zugriff auf Ihren Service von überall in Ihrer Anwendung mithilfe der statischen Syntax (: :):
%Vor%Dies ist der Mailer-Dienst:
Diese Leute sollten in hohem Grade austauschbar sein, heute benutzen Sie vielleicht einen Eloquent als Ihr ORM und speichern Daten in einer Datenbank, aber Sie müssen es möglicherweise zu etwas anderem ändern, einige foks speichern 100% ihrer Daten in Redis, Sie sollten also besser auf eine solche Änderung vorbereitet sein, indem Sie eine Interface (Vertrags-) Schicht zwischen Ihrem ORM und Ihrer Domänenlogin verwenden und wirklich für Ihre Schnittstellen entwickeln, nicht für Ihre konkreten Klassen. Taylor Otwell in seinem Buch sogar sagen, dass Sie Ihren Modellordner vollständig löschen sollten.
%Vor%Die Idee dahinter ist es, Implementierungen leicht zu vertauschen. In Laravel können Sie Laravel also über den IoC-Container mitteilen, welche Implementierung Sie verwenden:
%Vor%Wenn Sie also ein Repository verwenden, verwenden Sie Ihr PostInterface:
%Vor%Laravel IoC-Container wird dieses Repository automatisch mit einer Instanz von DbPost instanziieren. Und wenn Sie es jemals zu Redis ändern müssen, müssen Sie nur eine Zeile ändern:
%Vor%Der Dümmste der Awesomer.
Ansichten sollten nur für die Anzeige von Informationen verantwortlich sein. Ansichten sollten sich Ihrer Modelle, Dienste, Repositorys oder anderer Elemente in Ihrem System nicht bewusst sein. Views sollten von Webdesignern editiert werden können. Je mehr Code auf ihnen steht, desto mehr Bugs bringt Ihr Nicht-PHP-Programmierer-Designer mit. Ihr Controller sollte die Informationen aus Ihren Repositorys sammeln und an Ihre Ansichten weitergeben:
%Vor%Und die einzige Verantwortung Ihrer Ansicht sollte zeigen, dass Daten:
%Vor%Wie formatieren Sie Ihre Daten? Sie schreiben rohe Eigenschaften in Ihre Ansichten, aber Sie sollten hinter den Kulissen Presenter verwenden, um Ihre Daten zu präsentieren. Präsentatoren verwenden normalerweise das Decorator Design Pattern, um Ihre Daten so zu formatieren, dass sie in Ihren Seiten dargestellt werden. Dies ist ein Beispiel mit Shawn McCools LaravelAutoPresenter:
%Vor%Tags und Links php model-view-controller orm laravel