Aus einer PM an mich (Auszug)
Zitat von
banaguitar:
Hey Frank,
...
Was würdest Du mir raten?
...
Ich dachte, dass meine Antwort ggf. für alle interessant ist:
MVC/MVP war mir nicht „genug“ – daher habe ich mich für meine Projekte zu MVVM entschieden.
Ich habe mich seht intensiv mit diesem Thema beschäftigt. Mein Fazit:
1.) Wir programmieren nicht in C# und daher halte ich mich nicht zu 100% an die MS-Regeln für MVVM, weil ich einfach sage, dass man es mit Delphi besser machen kann. (Oje, ich höre schon den Aufschrei)
2.) Das Schicht-Model von MVVM muss eingehalten werden, wenn nicht geht alles schief. Das bedeutet auch eine klare aufgaben Trennung. Die View – die im eigentlichen nicht unserem Form entspricht, da ein Form mehrere Views haben kann sollte möglichst keinen Code enthalten. Da wir aber für unsere Forms „echten Code“ haben und nicht nur eine X(A)ML, sehe ich es nicht ganz so strikt. Beispiel OnDrawCell eines StringGrids.
3.) Sicherlich kann es für einen View mehr als ein Viewmodel geben. Ist aber aus meiner Sicht eher selten. Stellt aber i.d.R. kein Problem dar.
4.) Das Model ist übrigens nicht die Datenbank-Schicht, auch wenn das in vielen Tutorials so dargestellt wird.
5.) Man braucht für MVVM kein Framework! Ohne Framework ist es einfach viel mehr Arbeit und kann schnell unübersichtlich werden. Ist aber machbar.
6.) Ein Framework für MVVM zu schreiben ist nicht ganz einfach – ich kann ein Lied davon singen. Leider haben mich andere Aufgaben davon abgehalten meine #D.MVVM in Version 3.0 fertig zu stellen, daher arbeite ich immer noch in den verschiedenen Projekten mit meiner Version 1.0, 2.0 und 2.5 – wobei der Ansatz der 3.0 einfach das ist was „jeder“ braucht. Btw. Ggf. kommt etwas direkt in der
RTL von EMBT. (Dazu gab es eine Frage im letzten Onlinebefragung)
7.) Änderungen an der View erfolgen mit einem Aufruf von PropertyChange mehr nicht (so der MS Ansatz). Das ist natürlich Quark. Dem Aufruf kann ich problemlose ein Integer mitgeben (Level 1), damit die View nur das aktualisieren muss was gefordert ist. Ich kann aber auch ggf. mit dem Integer einen Pointer übermitteln um in einem Rutsch auch direkt Daten mit zu geben. (Level 2). Level 3 wäre dann direkt über ein Framework und einer Vermittlerschicht den Setter einer Komponente auf zu rufen.
Meine Empfehlung – Start Simple.
View first. Also erst die View (Form) erzeugen. Die View erhält dann ein ViewModel (Property Injection)– die View darf ja das Viewmodel kennen, nur nicht umgekehrt.
Die View gibt dann dem ViewModel eine Call-Back Procedure:
Procedure PropertyChange(aWhat : Integer);
In dieser Procedure ist eine große Case für die Integer Werte:
Delphi-Quellcode:
Case aWhat of
0 : begin // Refresh All
end;
1 : EdName.Text := fViewModel.Name; // .Name ist eine Property vom Viewmodel.
...
end; // of case
usw. Natürlich kann man auch einen Aufzählungstyp nehmen, aber das war mir immer zu viel Arbeit. ggf. Konstanen für die Aufruf.
Delphi-Quellcode:
Const
cRefreshAll = 0;
cName = 1;
...
Delphi-Quellcode:
if fName <> aValue then
begin
fName := aValue;
PropertyChange(cName);
end;
Delphi-Quellcode:
{$SCOPEDENUMS ON}
Type
TRefresh = (All,Nachname,Vorname,Strasse,Ort);
Für das Model geht es ähnlich.
Ich halte übrigens beim nächsten
Kongress in Amsterdam mal wieder einen Vortrag zu MVVM.
Grüsse
Mavarik
