nicht angemeldet
Rolf BHallo Jonathan,
ich glaube, dass Methodpark das falsch darstellt. Der Controller ist nicht der ständige Vermittler zwischen View und Model.
Das Bild in der Wikipedia zeigt es klarer: Wer kennt wen?
Controller: Kennt View und Model, und bringt die beiden auch zusammen View: Kennt das Model, aber nicht den Controller Model: Kennt nur sich selbst.
Falls eine Kommunikation vom View zum Controller oder vom Model zum View oder Controller erforderlich ist, kann das über ein Notification-System geschehen (z.B. Events oder Callbacks). Das ist in einer länger laufenden Anwendung deutlich relevanter als in der Request-Response Programmierung einer Webseite.
In einer Client-Application oder einer SPA-Website ist es durchaus sinnvoll, dass Modelländerungen automatisch ans UI übertragen werden. Dafür verwendet man UI-Mapper, und Modellklassen, die bei jeder Attributänderung change-Events erzeugen. Ein View kann auch für Aktionen Events auslösen, die der Controller beobachtet und darauf reagiert. Aber das dafür nötige Setup ist aufwändig, weswegen man gut überlegen muss, wieweit man sich für den Server-Code einer Webseite an die reine Lehre hält.
In den WebForms von ASP.NET ist es beispielsweise so, dass jeder POST vom Client erstmal beim Framework landet. Das baut das Server-Gegenstück zur Clientdarstellung auf, und tut dann so, als würde es darauf ein Event auslösen. Fühlt sich beim Programmieren an wie Windows Forms, ist aber ein Hammer an Overhead. Das spätere ASP.NET MVC macht es dann anders, man schreibt Controller-Klassen, die bekommen an Hand der URL Actions. Die GET- und POST-Daten werden vom Framework bereits in Fachklassen umgewandelt, soweit möglich. Und der Controller besorgt die Modelldaten, pflegt die Action ein, speichert die Modelländerungen und erzeugt einen neuen View. Das Erstellen der Action kann man in diesem Bild als einen Teil der View-Schicht auffassen. Und der View ist auf dem Server eben nur ein flüchtiges Ding, das dazu dient, die Client-Antwort zu transportieren. Das kann HTML sein, oder auch XML oder JSON, je nach genutzter Schnittstelle.
Ein solcher View kennt aber eben auch das Modell. Er kann darauf herumnavigieren, Daten zusammenstellen und ggf. aufbereiten, aber nicht ändern. Das macht nur der Controller, auf Grund der Action. An dieser Stelle lässt sich der Code durchaus sortieren. Ein Controller kann beispielsweise dadurch schlank gehalten werden, indem er das Befehlspattern verwendet, d.h. für jede Aktion erzeugt er das passende Command-Objekt und ruft es auf. Dieses Objekt weiß dann, wie die Aktion durchzuführen ist, es weiß bei einer Webseite ggf. auch, wie die Daten aus dem Request zu holen sind, und der Controller ist nur der Manager, der die Beteiligten zusammenbringt.
Rolf
sumpsi - posui - obstruxi