Schichtenmodell in modernen Webanwendungen

[BlackScorp]

PS: Das bezog sich natürlich nicht auf die ACL-Problematik.

wenn man 3 threads ließt dann verwechelt man die auch

[Gast]

Ein Controller darf zu keinem Zeitpunkt direkt mit einem Template kommunizieren - bspw. indem er Änderungen am DOM vornimmt. Stattdessen stellt ein Controller einen konkreten Funktionsumfang bereit, an welchem sich die Templates, je nach Bedarf, frei bedienen können.

ist nicht genau das der sinn eines jeden mvc-js frameworks ?

[gerhrgk]

Ich denke, der Controller sollte eher das View mit Daten befüllen. Das View selbst fragt nichts. Oder?

Besonders, wenn man ein einheitliches Interface für verschiedene Ebenen aufbauen möchte (z.B. CGI Konsole) ist es ratsam, dass das View keinen Einfluss auf den konkreten Lauf der Applikation hat.

[Roro]

Ich denke, der Controller sollte eher das View mit Daten befüllen. Das View selbst fragt nichts. Oder?

So machen es zumindest die meisten Web-Frameworks - nicht nur im PHP-Umfeld. Es gibt oftmals jedoch auch sog. View-Helper, z.B. im Zend Framework, die ihre Daten aktiv in der View beziehen... hat gewisse Vorteile, würde ich jedoch vermeiden wenn möglich.

[jack88]

@Chriz

Irgendwie finde ich ist MVC da generell kaputt. Heißt es nicht eine Klasse sollte genau eine Aufgabe haben?

Nein, das heißt es nicht. Es heißt eine einzige Verantwortung pro Klasse und nicht eine Aufgabe pro Klasse. Nach Deiner Interpretation des Single-Responsibility-Prinzips dürfte eine Klasse nicht mehr als eine public-methode bereitstellen.

Eine konkrete ActionController-Klasse soll konkrete Action-Methoden für einen bestimmten Aufgabenbereich bereitstellen (wie jede andere Klasse auch). Dabei ist es egal ob es 10, 20, 50 oder 100 Methoden sind. Es sind so viele wie nötig. Wenn ein Taschenrechner nur 4 Rechenarten unterstützt dann sind es 4, bei zwanzig Rechenarten müssen es eben 20 sein. Darin sehe absolut keinen Verstoß gegen das Single-Responsibility-Prinzip.

vg
jack

[jack88]

@lottikarotti

Die Architektur von AngularJS zielt im Speziellen darauf ab, Controller unabhängig von Templates zu entwickeln. Ein Controller darf zu keinem Zeitpunkt direkt mit einem Template kommunizieren - bspw. indem er Änderungen am DOM vornimmt.

Ich behaupte einfach mal, dass der UserController in Deinem Beispiel nicht nur mit dem Template kommuniziert, das DOM ändert, sondern sogar das Template auch noch initialisiert.

Dieses Beispiel demonstriert, wie man beliebige Templates um einen Controller herum aufbauen kann. Das funktioniert in dieser Form auch nur, weil der Controller keinerlei Abhängigkeit zu den Templates aufweist.

Nur weil die Abhängigkeiten in den Controller mittels DI dynamisch injiziert werden, bedeutet das nicht, daß es keine Abhängigkeiten gibt. Ist $scope etwa keine Abhängigkeit?

Das macht den Controller extrem flexibel und jederzeit wiederverwendbar.

Dein Beispielcontroller ist komplett an seinen $scope (Ausführungskontext) gebunden und deshalb genauso wenig flexibel oder wiederverwendbar wie jeder andere Controller auch.

vg
jack

[lottikarotti]

Hallöchen,

Ich behaupte einfach mal, dass der UserController in Deinem Beispiel nicht nur mit dem Template kommuniziert, das DOM ändert, sondern sogar das Template auch noch initialisiert.

Klar tut er das, jedoch unter der Haube. Allerdings sollte im Rahmen der eigenen Implementierung eines Controllers, niemals direkt mit dem DOM kommuniziert werden, um Abhängigkeiten zu einem DOM-Kontext zu vermeiden. Die Aufgabe des Controllers beschränkt sich, simpel ausgedrückt, auf die Dekoration von $scope.

Nur weil die Abhängigkeiten in den Controller mittels DI dynamisch injiziert werden, bedeutet das nicht, daß es keine Abhängigkeiten gibt. Ist $scope etwa keine Abhängigkeit?

Ich habe nie behauptet, dass ein Controller gar keine Abhängigkeiten hat. Dennoch sind Controller unabhängig vom DOM bzw. den Templates, welche darauf aufgebaut sind. Das ist Sinn und Zweck der Architektur.

Dein Beispielcontroller ist komplett an seinen $scope (Ausführungskontext) gebunden und deshalb genauso wenig flexibel oder wiederverwendbar wie jeder andere Controller auch.

Das Model, hier $scope, ist quasi das Werkstück eines Controllers. Dieses wird vom Controller initialisiert, geformt und nach Wünschen der Templates manipuliert. Dennoch kann der Controller völlig frei in absolut unterschiedlichen Templates die verschiedensten Aufgaben erfüllen. In meinem ziemlich minimalistischen Beispiel wird der selbe Controller für 3 unterschiedliche Templates, welche verschiedene Aufgaben haben, verwendet. Wo das nun unflexibel ist, erschließt sich mir nicht.

Viele Grüße,
lotti

[jack88]

Hallöchen

Das Model, hier $scope, ist quasi das Werkstück eines Controllers.

Der $scope ist bei angularjs kein Model im Sinne von MVC, sondern ein ViewModel. Dein Beispielcontroller kommuniziert also nur mit dem Datenmodel der View. Durch das bidirektionale Databinding zwischen der View und dem ViewModel ist es nicht mehr erforderlich direkt auf dem DOM zu operieren, der Entwickler muss sich nicht mehr selbst um die Synchronisation der View mit den ViewDaten kümmern. Das ist (verkürzt dargestellt) schon alles.

Die „Templates“ in Deinem Beispiel, sind im Grunde genommen, nichts anders als Einzelteile (Partials) einer einfachen Kundenverwaltung-View (user darstellen, user hinzufügen, user löschen). Genauso wie in MVC üblich beinhaltet der Usercontroller die Steuerungslogik dieser UserView. Der Controller ist hier genauso an den Funktionsumfang einer bestimmten View gebunden wie in jeder anderen MVC-Anwendung auch. Worin siehst Du hier überhaupt eine größere Flexibilität oder Wiederverwendbarkeit des Controllers?

Es gibt in diesem konkreten Fall sogar noch einen gravierenden Nachteil. Falls Du die drei Templates mal zusammen, also innerhalb einer View verwenden möchtest, dann werden drei unabhängige $scpoes/ViewModels erzeugt. Diese ViewModels kennen sich nicht und haben jeweils eine eigene Datenbasis, sie benutzen aber alle denselben Controller! Das bedeutet ganz konkret, daß z.B. das Löschen, oder das Hinzufügen eines Users keine Auswirkungen mehr auf die Darstellung in den anderen Bereichen, wie z.B. in der UserList haben wird. Damit wären dann die Vorteile des bidirektionalen Databindings leider wieder außer Gefecht gesetzt - und gerade das mach AngularJs doch aus

vg
jack

[BlackScorp]

ViewModels gehören doch aber zu MVVM

[lottikarotti]

Hallöchen,

Der $scope ist bei angularjs kein Model im Sinne von MVC, sondern ein ViewModel. Dein Beispielcontroller kommuniziert also nur mit dem Datenmodel der View. Durch das bidirektionale Databinding zwischen der View und dem ViewModel ist es nicht mehr erforderlich direkt auf dem DOM zu operieren, der Entwickler muss sich nicht mehr selbst um die Synchronisation der View mit den ViewDaten kümmern. Das ist (verkürzt dargestellt) schon alles.

Also ist der Controller unabhängig vom View, auf Grund der $scope-Mechanik - das sagte ich ja bereits. Über die korrekte Terminologie bei einem derart abstraken Thema, das zu weiten Teilen sowieso Interpretationssache ist, zu diskutieren, ist mir aber ehrlich gesagt zu mühselig.

Die „Templates“ in Deinem Beispiel, sind im Grunde genommen, nichts anders als Einzelteile (Partials) einer einfachen Kundenverwaltung-View (user darstellen, user hinzufügen, user löschen). Genauso wie in MVC üblich beinhaltet der Usercontroller die Steuerungslogik dieser UserView.

Das widerlegt ja nicht die Tatsache, dass drei unterschiedliche Templates auf den selben Controller zugreifen (können).

Der Controller ist hier genauso an den Funktionsumfang einer bestimmten View gebunden wie in jeder anderen MVC-Anwendung auch.

Nö.

Worin siehst Du hier überhaupt eine größere Flexibilität oder Wiederverwendbarkeit des Controllers?

Dass drei unterschiedliche Templates einen Controller verwenden können, verstehe ich bereits als Wiederverwendbarkeit. Flexibel wird das Ganze, wenn man Konfigurationen anbietet.

Es gibt in diesem konkreten Fall sogar noch einen gravierenden Nachteil. Falls Du die drei Templates mal zusammen, also innerhalb einer View verwenden möchtest, dann werden drei unabhängige $scpoes/ViewModels erzeugt. Diese ViewModels kennen sich nicht und haben jeweils eine eigene Datenbasis, sie benutzen aber alle denselben Controller! Das bedeutet ganz konkret, daß z.B. das Löschen, oder das Hinzufügen eines Users keine Auswirkungen mehr auf die Darstellung in den anderen Bereichen, wie z.B. in der UserList haben wird. Damit wären dann die Vorteile des bidirektionalen Databindings leider wieder außer Gefecht gesetzt - und gerade das mach AngularJs doch aus

Diese Probleme sind bereits gelöst. Dafür gibt es Direktiven und Services.

PS: Ich wollte nicht den Eindruck erwecken, als wäre die Architektur von AngularJS eine eierlegende Wollmilchsau Das Konzept ist für einen Anfänger allerdings sehr interessant und kann viel zum Verständnis von abstrakten Themen wie MVC, MVVM usw. beitragen.

Viele Grüße,
lotti

[jack88]

Also ist der Controller unabhängig vom View, auf Grund der $scope-Mechanik

Wenn das so ist, dann benenne doch einfach mal in Deinen Templates den „user“ z.B. in „benutzer“ um:

<ul data-ng-controller='UserController'>
    <li data-ng-repeat='benutzer in usres'>{{benutzer.username}} ({{benutzer.email}})</li>
</ul>

Wenn der Controller unabhängig von der View/Präsentationsschicht ist, dann sollte die Anwendung doch weiterhin einwandfrei funktionieren?

Du kannst es auch gerne umgekehrt versuchen, lass die Templates so wie sie sind und ändere nur den Controller:

...
$scope.benutzerliste= [
   {benutzername: 'foo', emailadresse: 'foo@bar.de'},
   {benutzername: 'bar', emailadresse: 'bar@foo.de'}
];…

Es wurde hier jeweils nur eine Komponente geändert und die Anwendung wäre in beiden Fällen ohne eine entsprechende Anpassung der jeweils anderen Komponente nicht mehr funktionsfähig. Meinst Du nicht auch, daß das im Widerspruch zu dieser Aussage steht:

„weil der Controller keinerlei Abhängigkeit zu den Templates aufweist “?

Deshalb sage ich es gerne nochmal „Der Controller ist hier genauso an den Funktionsumfang einer bestimmten View gebunden wie in jeder anderen MVC-Anwendung auch. “

Dass drei unterschiedliche Templates einen Controller verwenden können, verstehe ich bereits als Wiederverwendbarkeit.

Unter Wiederverwendbarkeit versteht man in der Programmierung eigentlich was anderes http://de.wikipedia.org/wiki/Wiederverwendbarkeit.

Nach Deinem Verständnis erhöht sich die Wiederverwendbarkeit des Controllers mit jeder Komponente, die mit diesem Controller interagieren kann. Das würde im Umkehrschluss bedeuteten, daß ein maximal wiederverwendbarer Controller alle Komponenten bedienen müsste. Das hat nichts mit Wiederverwendbarkeit zu tun.

Es liegt in der Natur der Sache, daß ein konkreter Controller (konkrete View und konkretes Modell übrigens genauso) nicht bzw. nur sehr eingeschränkt wiederverwendbar ist.

Eine wiederverwendbare Softwarekomponente muss bis zu einem gewissen Grad generisch sein. Eine Funktion wie sum(zahl1, zahl2) ist generisch und sehr gut wiederverwendbar. Eine Funktion wie sumEinsPlusZwei() ist sehr spezifisch und daher nur sehr eingeschränkt/kaum wiederverwendbar.

Ein konkreter Controller ist viel zu spezifisch um wiederverwendbar zu sein. Andere Entwickler könnten Deinen Controller in Ihren Projekten nicht ohne Anpassungen einsetzen, es sei denn Sie würden exakt die gleiche Anwendung programmieren.

Das Konzept ist für einen Anfänger allerdings sehr interessant und kann viel zum Verständnis von abstrakten Themen wie MVC, MVVM usw. beitragen.

Ja, das Konzept von AngularJS ist interessant, aber Dein Beispiel halte ich für unpassend. Es stiftet mehr Verwirrung, als dass es zum besseren Verständnis von MVC beiträgt.

vg
jack

[Okinez]

„Der Controller ist hier genauso an den Funktionsumfang einer bestimmten View gebunden wie in jeder anderen MVC-Anwendung auch. “

Wenn Du dieser Auffassung bist, solltest Du dir aber nochmal genauer die Definition von MVC ansehen. In einer korrekten MVC-Umsetzung ist ein Controller eben nicht an ein View gebunden, auch wenn das wohl 99% der Web-Frameworks so handhaben und dann als MVC vermarkten.

[Trainmaster]

die Definition von MVC

Wo steht denn die Definition von MVC geschrieben?

Ansonsten kann ich aktuell zwei Artikel empfehlen: http://phpmagazin.de/artikel/Model-V...ndungen-171912 und http://phpmagazin.de/artikel/Was-nic...-Teil-2-171917

[jack88]

Wenn Du dieser Auffassung bist, solltest Du dir aber nochmal genauer die Definition von MVC ansehen.

Ein Controller der an eine View Informationen sendet, die diese nicht verarbeiten kann wäre genauso sinnlos wie eine View die mit einem Controller kommuniziert, der sie nicht versteht. Das ist mit „an den Funktionsumfang gebunden“ gemeint und soll die Abhängigkeit zwischen den beiden Komponenten verdeutlichen, die nach meiner Auffassung, aufgrund der Aufgabenteilung der Komponenten immer gegeben ist.