Hallo,
ich möchte meine Formulare mit Hilfe vom Spring-Framework mehr in Richtung MVP/MVC/MVVM aufbauen. Aber irgendwie drehe ich mich dabei im Kreis, da die ganzen gegoogelten Infos in D2010 mangels Bindings, GC, etc. nicht so einfach zu implementieren sind.
Als Beispiel soll mal ein einfacher modaler Dialog dienen: dem User wird ein gegebener ganzzahliger Geldbetrag angezeigt und er soll ihn über Eingabefelder in 1, 2, 5 und 10EUR Stücke aufteilen. Direkt bei der Eingabe (OnChange) soll eine Summe und der Restbetrag aktualisiert werden. Beim Verlassen der Eingabefelder (OnExit) sollen diese Rot angezeigt werden, wenn z.B. negativ oder über ein gegebenes Limit.
Der Anwendungsentwickler erhält also irgendein Interface mit Properties für den Betrag, die Limits der einzelnen Felder, eine Execute-Methode und weitere Properties für die zurückgelieferten Eingabewerte. Nun die erste Frage: Was steckt nun hinter diesem Interface? Ist es der Presenter oder sollte es eher eine "Überklasse" sein, welche die MVP-Triad enthält?
So was brauche ich also:
- Eine Model-Klasse, angesprochen über IModel
Ist soweit klar: es enthält die nötigen Daten für den Dialog, also die ganzen Properties. Diese würde ich dann auch dem Anwendungsentwickler, z.B. über den Presenter, als Model-Property rausreichen.
- Eine View-Klasse, angesprochen über IView
Ich möchte eigentlich nicht die einzelnen Eingabeelemente als MVP-Klassen runterbrechen. Für Listen macht das vielleicht noch sinn, aber ein Eingabefeld als Integer-View welche über ein Integer-Presenter mit einem Integer-Model als Observer verbunden wird?
Ich dachte mehr an eine Art passiven View, wobei ich hier die Controls über Wrapper-Klassen als Interfaces rausreiche (wie
hier) und die Events bzw. anonyme Methoden dann auch nur das Interface als Sender sehen.
Aber hier taucht schon das nächste Problem auf: ein Formular als Interface hat keine Referenzzählung. Damit kann ich es zwar leicht im Konstruktor des Presenter über DI einbinden, muss dann aber daran denken es im Destruktor wieder frei zu geben. Wenn ich das View irgendwann mal gegen ein referenzgezähltes View (oder eine einfache Mock-Klasse) austausche dann knallt es.
Alternativ könnte ich das Formular auch in eine Wrapper Klasse einbinden und dort die Control-Interfaces erzeugen. Nur dann können dies nicht für einfache Validierungen im Formular genutzt werden. Was wäre die bessere Lösung?
- Eine Presenter-Klasse, angesprochen über IPresenter
Ist soweit auch klar: Diese erhält IView und IModel über DI vom Konstruktor und sorgt für den Datenaustausch zwischen Model und View, sowie macht die nötigen Validierungen und Berechnungen selbst bzw. über das Model.
Hier habe ich das Problem, dass das View bei komplexeren Dingen den Presenter kennen sollte. Nur wenn ich den Presenter direkt als Interface (und nicht als Pointer) verlinke, dann kann ich den Presenter nicht dem Anwendungsentwickler zur Verfügung stellen da er nie freigegeben wird. Zudem bekomme ich dann Probleme mit zirkulären Units.
Unterm Strich weiss ich nicht so richtig wie ich anfangen soll. Entweder habe ich viel Code für Wrapper/Zusatzlayer und "Überklassen" oder ich muss zu viel tricksen (Interfaces über Pointer, Freigabe des View-Interfaces) und hoffen das mir das nicht mal später um die Ohren fliegt.
Die MVVM-Lösung mit DSharp gefällt mir, aber mein Delphi 2010 ist davon nicht so begeistert und wirft interne Fehler oder stellt die Arbeit gleich ganz ein.
Wie also am besten vorgehen?
Danke, und Ciao
Norman