- MVC gibts in diversen Varianten und jeder versteht etwas (leicht) anderes darunter. Insbesondere variiert die Kopplung zwischen View und Controller und die Granularität des Modells.
- daneben gibts noch MVC-Varianten, die sich nicht mehr MVC nennen. Beispielsweise MVVM. Es gibt aber auch noch PAC und MVP und keine Ahnung was alles.
- Ja im "originalen" MVC kommunizieren M und V "direkt". Dir Frage ist aber was "direkt" nun heißt. Teilweise sind diese Kommunikationswege über Observer o.ä. realisiert.
- Wie schlimm diese direkte Kommunikation ist, hängt auch davon ab, wie das Modell aussieht. Das kann zum einen deine echte Geschäftslogik sein, aber auch quasi ein Teil der
GUI-Schicht, die die Daten aus der Geschäftslogik weiter aufbereitet.
- Wichtig sind diese Patterns insbesondere für Leute, die Frameworks bauen, weil solche Patterns zum Kernkonzept eines Frameworks werden können.
- Man kann die Patterns auch händisch anwenden.
- Man sollte sich aber immer bewusst sein, dass diese Muster auch ihre Nachteile haben. Insbesondere können sie den Entwurf ziemlich schwerfällig machen.
- Ich finde es deshalb oft sinnvoller auf MVC u.ä. zu verzichten und
GUI-Schicht und Applikationslogik ohne einen Controller zu trennen. D.h. die
GUI kennt die Anwendungslogik aber nicht umgekehrt. Für die Kommunikation in die andere Richtung eignen sich Events. So ist die
GUI zwar Abhängig von der geschäftslogik, aber das ist logisch eh fast immer der Fall. Nur den Umgekehrten Fall will man i.d.R. strikt vermeiden. Man will nicht die Applikationslogik ändern müssen, nur weil sich was an der Darstellung geändert hat. Wenn sich aber die Anwendungslogik ändert, kommt man fast eh nicht umhin die
GUI zu ändern. Eine technische Entkopplung wird diese logische Kopplung nicht aufheben können und macht häufig nur den Entwurf komplizierter.
- Visitors sind etwas ganz anderes.
mfg
Christian