Was würde mein controller werden in diesen Szenarien in einer mvc-web-Anwendung?

Question

1) Wo kommt der Startseite Ihrer website passen in die "Controller"?Ich habe gesehen, einige Leute benutzen eine "Seite" controller zu Griff statische Seiten wie, über, home, Kontakt, etc., aber mir erscheint das nicht wie eine gute Idee.Würde die Schaffung einer bestimmten regler nur für Ihre homepage eine bessere option sein?Nach alle, es muss für den Zugriff auf mehrere Modelle und nicht wirklich zum fließen gut mit der ganzen, einen controller pro-Modell die Theorie, dass manche Menschen verwenden.

2) Wenn Sie benötigen ein dashboard für mehrere Arten von Benutzern, wäre das eine dashboard-controller, der hätte toggle-code, abhängig von dem Benutzer, oder würden Sie sagen, eine dashboard-Aktion innerhalb der einzelnen controller pro Benutzer?Für Beispiel, admin dashboard, account/dashboard, etc.

3) Es scheint mir, dass die ganze einfache CRUD-Beispiel funktioniert wie ein Charme, wenn Sie versuchen zu erklären, Controller, aber wenn man erst einmal über die einfachen Funktionen, bricht es unten und kann die Ursache für Ihre Controller zu bekommen unhandlich.Warum haben manche Menschen wählen zu schaffen ein login-controller, wenn die anderen stellen Sie eine login-Funktion im Benutzer-controller?Ein Grund, warum ich denke, dass viele von uns kommen von einer anderen Seite nähern hintergrund und es ist schwer zu denken, der Controller als "Objekte" oder "Nomen", weil Seiten nicht immer so funktioniert.Fall in Punkt, warum auf der Erde würden Sie wollen, erstellen Sie eine "Seiten" - controller, die behandeln würden, die Seiten, die wirklich nichts miteinander zu tun zu haben, nur um einen "container" zu passen, Aktionen in.Scheint einfach nicht richtig zu mir.

4) Sollten die Controller haben mehr zu tun mit einem Anwendungsfall als ein "Objekt", dass Aktionen ausgeführt werden können?Für alle intensiven Zwecke, Sie erstellen einen Benutzer-controller, hat jede Aktion in Ihrer gesamten app.Oder Sie können eine controller pro "Bereich von Interesse" wie manche sagen.Oder Sie könnten einen controller per-view, wenn Sie wollten.Es gibt so viel Spielraum, dass es macht es schwer herauszufinden, eine einheitliche Methode zu verwenden.

Controller sollte nicht verwirrend wohl, aber für einige Grund, Sie baffle die Hölle aus mir heraus.Jede hilfreiche Kommentare würde sehr geschätzt werden.

Answer 1

1) Ich benutze eine einfache homebrew-Satz von Klassen für einige meiner MVC-Zeug, und es betrifft die controller-Namen zu handeln und anzeigen von Namen (es ist ein Front-Controller-Stil, ähnlich Zend).Für eine Allgemeine Website, nehmen wir an, es hat eine Startseite, Datenschutzerklärung, Kontakt-Seite und eine about-Seite.Ich weiß nicht wirklich wollen, um getrennte regler für all diese Dinge, sodass ich halte Sie in meinem IndexController, mit der Funktion Namen wie actionIndex(), actionPrivacy(), actionContact(), und actionAbout().

Zu gehen zusammen mit, dass, in meinen Ansichten-Verzeichnis habe ich ein Verzeichnis der Vorlagen im Zusammenhang mit der jeweiligen Aktion.Durch Standard, jede Handlung sucht automatisch nach einer Vorlage verbunden, obwohl Sie festlegen können, wenn Sie es wünschen.So actionPrivacy() würde mich über eine Vorlage-Datei an index/privacy.php, actionContact() würde mich über ein index/contact.php, etc.

Natürlich, dies bezieht sich auf die URLs als gut.So eine url Treffer http://www.example.com/index/about würde laufen actionAbout(),, das würde das laden der About-Seite Vorlage.Seit der about-Seite ist komplett von statischen Inhalten, meine actionAbout() tut absolut nichts, anderes, als eine öffentliche Aktion für den Front-Controller und ausführen.

Zur Beantwortung der Kern Ihrer Frage, ich setze mehrere "Seiten" in einen einzigen controller, und es funktioniert gut für meine Zwecke.Ein Modell pro controller ist eine Theorie, die ich glaube nicht, dass ich versuchen würde, zu Folgen, wenn die Arbeit mit Web-MVC, wie es scheint zu passen, eine Anwendung mit Zustand viel besser.

2) Dafür hätte ich mehrere Controller.Nach den gleichen Methoden, die ich benutze, würde ich haben /admin/dashboard und /account/dashboard wie schlagen Sie vor, obwohl es keinen Grund gibt, Sie nicht verwenden können, die gleiche (oder Teile desselben) Vorlagen.

Ich nehme an, wenn ich hatte eine Unmenge verschiedene Arten von Benutzern gibt, würde ich die Dinge etwas generisch und nur ein controller und eine mod_rewrite-Regel für die Beladung.Es würde wahrscheinlich davon abhängen, wie funktionell-Komplex ist das dashboard, und was der account eingerichtet ist.

3) Ich finde CRUD-Funktionalität nur schwer zu implementieren, die direkt in jede Schicht der MVC und habe es immer noch sauber, flexibel und effizient.Ich mag abstrakte CRUD-Funktionalität in eine service-Schicht, die jedes Objekt kann anrufen, und haben eine Basis-Objekt der Klasse, von dem aus ich kann verlängern alle Objekte benötigen, CRUD.

Ich würde vorschlagen, unter Verwendung von ein paar von die PHP-ORM-frameworks da draußen für CRUD.Sie können tun, Weg mit viel Mühe, immer eine schöne Umsetzung.

In Bezug auf die login-controller versus user-controller, ich nehme an, es hängt von Ihrer Anwendung Domäne.Mit meiner Art der Programmierung, ich würde dazu neigen zu denken von "logging in", wie eine einfache operation innerhalb der Domäne eines Benutzer-Modell, und so haben eine einzige operation für Sie in einem Benutzer-controller.Um genauer zu sein, ich hätte das UserController instanziieren Sie ein user-Modell und nennen einen login-routine auf dem Modell.Ich kann Ihnen nicht sagen, dass dies der richtige Weg, denn ich konnte es nicht sicher sagen, was der richtige Weg sein soll.Es ist eine Frage des Kontextes.

4) Du hast Recht bezüglich der Spielraum.Sie konnte einfach erstellen Sie eine controller, die verarbeitet alles, was Ihre app/Website tun wollte.Aber ich denke, Sie würden Zustimmen, dass dies zu einem Wartungs-Albtraum.Ich bekomme immer noch die jibbly-jibblies denken, über meinen letzten job bei einem Marktforschungsinstitut, in denen die PHP-interne app wurde von einem übersee-team mit, was ich nur annehmen können, war wenig-zu-keine Ausbildung.Wir reden hier von 10.000 Linie Skripts behandelt die gesamte Website.Es war unmöglich, Sie zu pflegen.

Also, ich würde vorschlagen, Sie brechen Sie Ihre app/Website down in business-Bereichen domain und die Erstellung von Controllern basierend auf, dass.Herauszufinden, die grundlegenden Konzepte der app und gehen von dort aus.

Beispiel

Sagen wir, ich hatte eine Website über Seekühe, weil offensichtlich Seekühe rock.Ich möchte einige normale Seiten (über, Kontakt, etc.), Benutzer-account-management, einem forum, einer Bildergalerie, und vielleicht ein Forschungs-Dokument material-Bereich (mit der neuesten Wissenschaft über Seekühe).Ziemlich einfach, und eine Menge davon wäre statisch, sondern Sie kann beginnen zu sehen, den Zusammenbruch.

IndexController - Griffe über uns " - Seite, Datenschutz, generische statische Inhalte.

UserController - Griffe Konto erstellen, einloggen/aus, Einstellungen

PictureController - display-Bilder, handle uploads

ForumController - wahrscheinlich nicht viel, ich würde versuchen, Sie zu integrieren externe forum ist, was bedeuten würde, müsste ich nicht viel Funktionalität Sie hier.

LibraryController - zeigt eine Liste der neuesten Nachrichten und Forschung

HugAManateeController - virtuelle manatee umarmt in Echtzeit-über-HTTP

Dass wahrscheinlich haben Sie wenigstens eine grundlegende Trennung.Wenn Sie einen controller immer sehr groß ist, ist es wahrscheinlich Zeit, Sie brechen die business-Domäne in separaten Controller.

Es wird anders sein für jedes Projekt, so dass ein wenig Planung geht ein langer Weg in Richtung, welche Art von architektonischen Struktur, die Sie haben.

Web-MVC kann sehr subjektiv, denn es ist ganz anders als ein MVC-Modell, wo Ihr Antrag Status.Ich versuche, die wichtigsten Funktionen out-of-Controller beim Umgang mit web-apps.Ich möchte, dass Sie instanziieren ein paar Objekte oder Modelle, führen Sie eine Reihe von Methoden, basierend auf den Maßnahmen, und sammeln Sie einige View-Daten, pass off zu der Ansicht, sobald es fertig ist.Je einfacher, desto besser, und ich habe die core business logic in die Modelle, die angeblich Vertreter der Zustand der Anwendung.

Hoffe, das hilft.