Ich kratze mit Angularjs an der Oberfläche und dachte, ich würde eine konzeptionelle Frage an den feinen Leuten von SO vorbeitragen. Dies ist eine neue Frage von einem erfahrenen Entwickler.
Die Anwendung verfügt über Dashboard-Anforderungen ... eine einzelne Seite, auf der sich viele Teile der Anwendung befinden. Unterschiedliche Benutzertypen erhalten unterschiedliche Dashboards. Wir haben bereits ein Legacy-Backend, daher besteht die erste Aufgabe darin, das Dashboard so zu erstellen, dass viele Bits aus seiner neuen RESTful-Service-Schicht angezeigt werden.
Ich frage mich, wie ich konzeptionell über die Controller nachdenken sollte, die benötigt werden, um dies zu unterstützen?
Die erste Frage ist ... sollten sie modellzentriert oder sichtzentriert sein? Mit anderen Worten, sollten sie "sichtorientierte" Controller sein, die das Wort "Dashboard" enthalten? Oder sollten sie sich mehr auf die Modellelemente konzentrieren, die sie repräsentieren, wie "Aufgaben", "Kontakte", "Benachrichtigungen". Oder sollte es beides geben, wo die Dashboard-Controller mit modellzentrierten Controllern arbeiten?
Die nächste Frage ist ... welche Granularität sollten die Controller repräsentieren? Wenn es sich um sichtorientierte "Dashboards" -Controller handelt, sollten sie "ManagerDashboardController" und "WorkerDashboardController" lauten? Wenn es sich um modellzentrische Controller handelt, sollten Controller wie "LateTasks" & amp; "OnTimeTasks", da ich sie in verschiedenen Bereichen des Dashboards mit etwas anderen Daten anzeigen muss?
Ich bin auf der Suche nach konkreten Ratschlägen, basierend auf realen Erfahrungen und / oder Verweisen auf großartige Links, die ich noch nicht gefunden habe.
Dies ist sehr subjektiv, aber hier ist meine Antwort auf Ihre Fragen
sollten Controller modellzentriert oder sichtzentriert sein?
Es hängt (wie immer) von mir ab, dass ich immer versuche, kleine Controller für die verschiedenen Teile der Seite zu haben.
Einige Teile der Seite sind sehr sichtorientiert (normalerweise die, die von den verschiedenen Ansichten gemeinsam genutzt werden). Ich habe normalerweise eine menuCtrl, eine headerCtrl und footerCtrl. Diese Ctrls sind sehr an diese Teile der Seite gekoppelt, um sie auf die Ansicht zu zentrieren.
Die anderen Teile der Ansicht, diejenigen, die geschäftlich verwandt sind, sind viel mehr an die Geschäftsregeln und an die Erweiterung des Modells gekoppelt, also mache ich diese Regeln modellzentriert. In der Geschäfts-App eines Kontos hätte ich wahrscheinlich eine accountCtrl, eine ownerCtrl und so weiter. Dadurch kann ich sie bei Bedarf in verschiedenen Ansichten wiederverwenden (und sie sind viel einfacher zu testen)
Welche Granularität sollten die Controller repräsentieren?
Das Kleinste wie möglich. Versuchen Sie, kleine Controller zu verwenden, die das Modell für verschiedene Teile der Seite vorbereiten. Wenn Sie einen großen Controller haben, wird es schwer zu testen, zu warten und Sie werden wahrscheinlich Code für verschiedene Teile Ihrer Anwendung kopieren müssen.
Ratschläge und Empfehlungen mit Controllern
Halten Sie sie klein.
Vermeiden Sie die DOM-Manipulation in ihnen (verwenden Sie stattdessen Anweisungen).
Verwenden Sie die Controller nur zur Vorbereitung des Modells. Wenn möglich, delegieren Sie die gesamte Logik Ihrer App an Dienste. Wenn Sie dies tun, ist es nicht wirklich wichtig, ob Ihr Controller View-centric oder Model-centric ist.
Wie ich schon sagte, ist das eine sehr subjektive Angelegenheit und ich bin mir sicher, dass viele Leute mir nicht zustimmen werden.Ich hoffe, das könnte dir helfen.
Hier sind meine Ansichten aus der Entwicklung von Geschäftsanwendungen in Angular für die letzten 6 Monate:
$watch es) Ich habe festgestellt, dass die Controller in einer Angular-App genau wie in herkömmlichen MVC-Frameworks wirklich super schlank sein sollten. Wenig oder gar keine Geschäftslogik sollte in den Controllern enthalten sein und sollte stattdessen in Ihren Modellen enthalten sein. Ich kam zu dieser Schlussfolgerung, nachdem ich die folgende Zeile von einer Präsentation von Miško Hevery gehört hatte: " der Zweck von der Umfang bezieht sich auf das Modell und nicht auf das Modell . " Das war die wertvollste und aufschlussreichste Zeile, die ich von dieser Präsentation bekommen habe (obwohl ich empfehle, das ganze Video anzuschauen); Diese Linie führte direkt dazu, dass ich meine Controller um fast 50% -70% verschlank.
Zum Beispiel hat meine Firma ein Konzept von Order . Ich habe ein Modell erstellt, das alle Eigenschaften dieses Geschäftsobjekts sowie sein Verhalten verkapselt und in die Controller eingefügt hat. Eine Geschäftsregel, die wir hatten, war die Möglichkeit, Booking (ein anderes Geschäftsobjekt) zu Order hinzuzufügen. Ursprünglich in meinem Controller, hatte ich eine $scope.addBooking -Funktion, die zuerst eine neue Booking erstellte, dann die Reihenfolge annahm und $scope.order.bookings.push(newBooking) tat. Stattdessen habe ich diese Geschäftslogik ( addBooking function) direkt in mein Order -Modell verschoben, und in der Vorlage könnte ich dann etwas wie <button ng-click="order.addBooking()">Add Booking</button> machen, ohne eine einzelne Codezeile in meinen Controller einzufügen.
Ein großer Teil des Codes, den ich meinen Controllern beilegte, als ich mit eckigen anfing, fand ich herausgenommen und entweder in meine Modelle, Anweisungen oder Dienste (meistens die ersten beiden in meinem Fall) eingefügt. Der Rest des Codes in meinen Controllern fiel fast alle in eine der oben genannten 3 Rollen, die ich oben aufgelistet habe. Es war entweder Initialisierungscode (z. B. Abfeuern einer AJAX-Anforderung zum Abrufen von Daten der relevanten Geschäftsobjekte), Bereichszuordnung von Objekten oder Bereichszuweisung von Funktionen, die den Anwendungsfluss betrafen (z. B. $scope.save oder $scope.cancel , die Sie zurückschicken könnten auf eine andere Seite).
Das ist eine interessante Frage, über die ich vorher noch nicht nachgedacht habe. Wenn ich View-centric höre, denke ich an einen Controller, der sich hauptsächlich mit der Ansicht und der Darstellung von Dingen beschäftigt. Ich denke, es sollte keine reinen View-Controller geben, da ein View-centric-Controller wahrscheinlich in eine Direktive umgewandelt werden kann. Sie haben View-centric-Controller als einen Dashboard -Controller bezeichnet, was sich wie etwas anhört, das definitiv zu einer generischen Direktive gemacht werden könnte. Ihre Anweisungen sollten den Großteil Ihrer Ansichtslogik kapseln, während sich Ihre Controller darauf konzentrieren, Ihre Modelle einfach der Ansicht für den Verbrauch auszusetzen (zurück zur Rolle des Controllers). Dies lässt mich denken, dass Controller häufiger modellzentriert sein sollten.
Ich glaube wirklich, die einzige Schlussfolgerung, zu der ich kommen kann, ist, wenn ein Controller anfängt, zu sehr auf die Ansicht zu zentrieren (mit vielen Variablen und Funktionen, die hauptsächlich mit dem View- und UI-Verhalten zu tun haben) in eine Direktive gezogen werden, wodurch dein Controller schlanker wird.
Grundidee
Ich bin also gerade dabei, eine Legacy-Code-Basis auf AngleJs in eine Web-Service-Architektur umzuwandeln, die auf einem erholsamen Ansatz beruht
Controller sind verantwortlich für die Verwaltung der Daten, die von der Ansicht aka der Webseite konsumiert werden. Meine persönliche Präferenz ist, dass es eine Eins-zu-eins-Beziehung zwischen dem Controller und der Ansicht gibt, der er dient. Basierend auf der Frage sollten Angular-Controller mehr Blick-zentriert sein. Ich bin mir sicher, dass es viele Leute gibt, die mir nicht zustimmen werden.
Wenn Sie Bedenken hinsichtlich der Erweiterbarkeit dieses Musters haben, sollten Sie Ihre Geschäftslogik und Ihren Datenzugriff innerhalb von Angular Services wie hier beschrieben . Dies bietet Ihnen eine enorme Menge an Wiederverwendung von Business-Logik-Operationen sowie Unit-Testability.
TLDR;
Die Spezifikationen für Angular ändern sich ständig und mit jeder neuen Version wird es einen neuen Standard geben. Eine zentrierte Architektur mit mehr Ansichten ist für diese Anwendung geeignet.
Für eine ausführlichere Lektüre zu diesem Thema empfehle ich Folgendes:
Tags und Links angularjs model-view-controller controller