MVVM in der Realität

**Union**

Ich habe mich in den letzten Tagen etwas mit MVVM beschäftigt. Setzt das jemand im Zusammenhang mit Delphi erfolgreich ein und falls ja, mit eigenem oder vorhandenem Framework?

Vor allem würde mich das Binding interessieren und wie man es elegant schafft, die Persistenz zu regeln sowie Informationen in den View zu bekommen, die er eigentlich nicht kennen darf aber (z.b. wegen Useability) kennen sollte.

Ich habe für das Binding bisher zwei Ansätze verfolgt:
* Verwenden der vorhandenen LiveBindings, die ja über das Observer-Pattern in TComponent einfach zu realisieren sind. Ist aber irgendwie sehr verschwurbelt, man sehe sich nur mal die seitenlangen Callstacks an.
* Erstellen eigener Bindingklassen. Momentan noch ohne (von Delphi vordefiniertem) Observer, sondern durch Zugriff von Events und Properties in die View-Komponenten über die erweitere RTTI. Also sowas wie Poor Man's Livebindings.

Einfache Darstellung eines konkreten Problems:

* Datenbank enthält Char Feld mit 20 Länge und nur Großbuchstaben sind zulässig
* Model enthält die Daten aus einem Satz der DB
* Viewmodel verwaltet die Daten des Model und die Logik
* Binding verknüpft Viewmodel mit
* View, in dem die Daten bearbeitet werden. Wenn ich jetzt hier ein Edit habe, sollte das optimalerweise nur 20 Zeichen in Großbuchstaben zulassen.

Ich persönlich fokussiere mich beim dem MVVM eher auf das Konzept des Viewmodels, also die Schnittstelle zwischen Daten und Darstellung. Mit einem Viewmodel wird deine UI-Metapher (also das Formular mit den Controls) hinsichtlich seiner Funktion testbar. Und *das* ist für mich der größte und entscheidende Vorteil.

Das Binding mache ich sehr konservativ, falls ich überhaupt mit Delphi arbeite. Aber selbst mit C# binde ich selten. Warum? Weil das VM die Daten i.A. nur dann benötigt, wenn eine Aktion/Command ausgeführt wird. Dann ist immer noch Zeit, die Daten aus der UI zu sammeln.

Das bei meinem derzeitigen Auftraggeber verwendete Framework macht die ganze Prüfung, und zwar über Attribute. Ob das in Delphi geht, weiß ich nicht, aber wenn nicht, arbeite ich hemdsärmelig mit den EditRepositoryItems von DevExpress.

Wie gesagt, das ist kein 'richtiges MVVM', aber mir ist es gleich.

**Union**

Zitat von Furtbichler:

Das bei meinem derzeitigen Auftraggeber verwendete Framework macht die ganze Prüfung, und zwar über Attribute.

Ach ja, die Attribute. Das geht natürlich über Delphi inzwischen auch. Etwas verkrampft über die RTTI (Delphi als Scriptsprache) aber es geht. Da die aber Bestandteil des Source sind gehe ich davon aus, dass bei dem von Dir eingesetzten Framework ein Source-Generator dabei sein muß der die Modelle generiert und dann mit den Attributen garniert:

markieren

Delphi-Quellcode:

			TKunde = class

public

  [MaxLen(20)]

  [UpperCase]

  property Name : string

end;

Oder allgemeiner, dann kann man sich evtl. holen was man will:

markieren

Delphi-Quellcode:

			TKunde = class

public

  [TableName('Kunden')]

  [FieldName('Name1')]

  property Name : string

end;

Und dann muß das ViewModel die Attribute holen und das Binding im View aus dem Viewmodel.

Fast genauso ist es. Es reicht jedoch nicht, wenn das Business Object die Formatinformation besitzt, denn das bindest Du ja nicht an die UI (jedenfalls ich nicht). Ich mappe das über das VM, und dort benötige ich dann noch die Verbindung zwischen VM-Property (welches an die UI gebunden wird) und BO-Property. Das geschieht hier mit einem Attribut "RefersToField":

markieren

Code:

			[RefersToObject(typeof(CustomerData))]

class CustomerVM

{

  [RefersToField("Name")]

  public string Name{get;set;}

...

irgendwie so jedenfalls.

**Union**

Das ist es was mir in der Realität so sauer aufstößt. Es werden toll klingende Modelle benutzt, man redet von "Information Hiding" und sauberen Schnittstellen. In Wirklichkeit gibt es trotzdem jede Menge Abhängigkeiten. Die werden dann unter neuem Namen verpackt. Zaubern kann ja keiner - bis auf die Marketing Leute die das und die zugehörigen Tools, Schulungen und Literatur unters Volk bringen.

**mquadrat**

Aktuell machen wir noch kein MVVM mit Delphi. Zukünftig werden wir eine Art MVVM-Light (Nein, nicht das .NET Framework

) einführen. Da wir schnittstellenkompatibel mit der alten Architektur bleiben müssen, kommt nur ein eigenes Framework in Frage.

LiveBindings können wir aktuell nicht nutzen, daher werden wir das Binding wohl selber machen müssen. Die Metadaten (für Validierung und das DB Mapping) werden wir über Attribute lösen, das umständliche auslesen über die RTTI werden wir beim ersten Aufruf machen und die Metadaten und das DB-Mapping dann in einem Dictionary parken. Nicht unbedingt aus dem Lehrbuch, aber wir können die Anwendung nicht von einem auf den anderen Tag komplett umstellen. Aktuell hoffe ich noch damit auch Binding-Paths realisieren zu können. Die Bindings selber dann nach dem Convention-Over-Configuration Prinzip.

Die Metadaten verwenden wir dann wahrscheinlich auch für automatisch generierte CRUD Webservices. Mal schauen, was mir da noch so einfällt

Zitat von Union:

In Wirklichkeit gibt es trotzdem jede Menge Abhängigkeiten. Die werden dann unter neuem Namen verpackt.

Nicht, wenn Du die Abhängigkeiten zwischen Datenmodel (DB) und deinen Datenklassen mit einem Tool erzeugst (Database first / Code first).

Ich kann mich jedenfalls damit anfreunden. Es ist nur etwas blöd beim entwicklen, man muss mehr planen, was aber auch nicht verkehrt ist.

**stahli**

Was ich bisher dazu gesehen habe hat mich nicht überzeugt. Für mich ist das zu kompliziert und wirkt eher wie Selbstzweck.

Letztlich versucht man ja, sich die Arbeit zu erleichern und komplexe Aufgaben einfach zu lösen. Mir scheint aber die Realiserung eines MVVM sehr aufwendig (und ein Grundverständnis zu entwickeln überhaupt schwierig).

Vielleicht liegt es ja an mir und meiner begrenzten Ausbildung...

Vielleicht erschließt sich mir ja etwas aus Stefans Vortrag (dürfte ja thematisch nahe sein)...

**Union**

Na Du hast ja sowas ähnliches versucht mit Deinem Framework. Jedenfalls so ein bischen. Selbstzweck ist es allerings gar nicht:

Man kann die Logik automatisiert testen, dadurch werden Tests auch reproduzierbar
Man ist plattformunabhängig

Aus meiner Sicht jedenfalls zwei Riesenvorteile.

**stahli**

Der Unterschied zu meinem Framework ist, dass bei mir beide Schichten (BL&Daten sowie GUI) völlig getrennt erzeugt werden und existieren und das Framework lediglich die GUI-Controls an bestimmte Daten (Objekteigenschaften) bindet.
So sind beide Schichten völlig losgelöst voneinander und sehr einfach zu erstellen. Man hat eine sehr einfache und übersichtliche Arbeitsumgebung - bzw. eigenlich zwei: eine für die BL&Daten und eine für die GUI. Man ist natürlich dann an das Framework gebunden.

Das MVVM-Beispiel vom DSharp habe ich kaum nachvollziehen können.
Vielleicht sieht es anders aus, wenn man das Prinzip erst mal verstanden hat, aber das ist mir damals nicht gelungen.
Für mich war das zu verwirrend und von der Programmierung her sah es mir auch aufwendig aus.