Zitat:
Mich persönlich hat bei dem MVC/MVP Modell immer gestört, dass man für meinen Geschmack zu viel Code erzeugt und trotzdem noch statische Abhängigkeiten hat
Das ist auch ansatzweise an deinem Beispiel sichtbar.
Das muss man wirklich zugeben. Die Menge an Code wächst enorm!
Bei großen Projekten wirkt sich das irgendwann nicht mehr so stark aus - und kann auch nicht umgangen werden.
Man sollte sich (bei großen Projekten) immer die Option offen halten, die
GUI einfach auszutauschen (durch
HTML-Oberfläche) oder zu erweitern (unterschiedliche Anzeigen gleichzeitig - sinnvoll: keine Ahnung; möglich: ja).
Mich stört beim "klassischen MVC", wie man es im WWW an jeder Ecke erklärt bekommt, dass die Trennung zwischen
GUI und Model nicht stark genug ist (vor allem die Richtung View --> Model).
Beipsiel (durchgezogener unterer Pfeil):
http://de.wikipedia.org/wiki/Model_View_Controller
Zusätzlich verwende ich immer einen Presenter zwischen View (
GUI) und Controller, denn es gibt Code, der weder in den Controller noch in die View (Formularcode) gehört. Weiterer Vorteil: mein Controller muss die konkrete
GUI (oder deren Anzahl) nicht kennen.
---
Was ich für wichtig und keine leichte Aufgabe halte, ist die richtige Positionierung der "echten Verbindungen". Es muss ja eine bidirektionale Verbindung aufgebaut werden (View <--> Model).
- Wer kennt wen ab wann.
- Sollen Verbindungen verändert werden (Edit-Feld soll ein den Wert eines anderes Business-Objektes repräsentieren)?