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.

[Furtbichler]

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:

Zitat von Furtbichler (Beitrag 1227624)

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:

Delphi-Quellcode:

TKunde = class
public
  [MaxLen(20)]
  [UpperCase]
  property Name : string
end;

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

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.

[Furtbichler]

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":

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 ;)

[Furtbichler]

Zitat:

Zitat von Union (Beitrag 1227640)

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.

[Union]

Zitat:

Zitat von stahli (Beitrag 1227830)

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.

Wo ist denn da der Unterschied? Du hast:

1. GUI (View)
2. Framework (Viewmodel)
3. Daten & BL (Model)

[stahli]

Ich habe nicht nachvollziehen können, wann welcher Teil erzeugt, initialisiert und aufgerufen wird.
Das gesamte Handling hat sich mir nicht erschlossen. Entsprechend konnte ich es nicht als einfach und erstrebenswert einordnen.

Ich will es ja nicht schlecht reden. Es war nur MEIN BISHERIGER Eindruck von der Sache. Bin halt etwas einfach gestrickt. ;-)

[stahli]

Gleich nochmal von mir (aber kein push):

Wie wäre es mit einer kleinen Aufgabestellung (z.B. Eltern und Kinder verwalten oder so), die mit verschiedenen Ansätzen per Videodokumentation vorgestellt werden?

Man könnte sich auf eine kleine Aufgabe einigen.
Wer teilnehmen will kann dann die Aufgabe mit seiner bevorzugten Arbeitsumgebung von Null an erstellen und dies mit Screenrecorder dokumentieren.

Ich wäre RIESIG GESPANNT auf die Ergebnisse und würde mich mit meinem ssFramework beteiligen.


Mein Projektvorschlag:
- Elternpaare registrieren (Vorname, Nachname, Alter, Geschlecht)
- Kinder zuordnen (ebenfalls Vorname, Nachname, Alter, Geschlecht)
- Daten speichern und laden
- Formularbreite und -höhe ändern über SpinBoxen und Formularcaption über Edit (wegen Demonstration des DataBinding)

[stahli]

War das wieder eine Schnapsidee von mir?
Ich denke mir, man könnte so einen Überblick über die attraktivsten Arbeitsansätze finden...

[Union]

Scheint ja wohl daran zu liegen dass es noch keiner so wirklich nutzt.

[stahli]

Ich weiß immer nicht, ob ich der Zeit um einige Jahre voraus bin oder hinterher hinke oder örtlich vielleicht doch woanders hin gehöre... :wink:

Es gibt ja immer wieder schlaue Hinweise, wie man (vielleicht auch ohne Delphi) Projekte am einfachsten, übersichtlichsten, schönsten und stabilsten aufbaut. Die Bemerkungen sind für mich aber zu abstrakt.

Ich würde mir alle entsprechenden Demovideos begeistert reinziehen.
Wenn man (vielleicht in einem eigenen Thread) eine kleine Aufgabe abstimmt würde ich mit meinem Framework auch gern den Anfang machen... (unter MVVM fällt das allerdings m.E. nicht wirklich - aber es unterstützt gut bei der Projektentwicklung)

[Union]

Also ich habe einen Lösungsansatz, den ich in Ausschnitten beschreibe.

Die View ist ein normales TForm. Beim Erzeugen wird das Binding erstellt.

Delphi-Quellcode:

constructor TfrmMain.Create(AOwner: TComponent);
begin
  ViewModel := TViewModelKunde.create;
  inherited;

  // Binding einzeln erzeugen
  FBindingList    := TBindingList.Create;
  FNameBindObject := TEditBinding.Create;
  FNameBindObject.Control := edtNameTest;
  FNameBindObject.ControlProp := 'Text';
  FNameBindObject.BindObject :=  ViewModel.Kunde;
  FNameBindObject.BindProp := 'Name';
  // Und hinzufügen
  FBindingList.Add(FNameBindObject);
  // Oder direkt
  FBindingList.Add(TEditBinding.Create(edtKdNrTest, ViewModel.Kunde, 'Text', 'Kdnr'));
  // Hier wird alles initialisiert
  FBindingList.Load;
end;

Im Viewmodel wird dann die UI-Relevante Logik implementiert, z.b. ob gespeichert werden darf.
unit Viewmodel.Kunde;

Delphi-Quellcode:

interface

uses Model.Kunde;

type
  TViewModelKunde = class
  strict private
    FKunde: TKunde;
    procedure SetKunde(const Value: TKunde);
    function GetCanSave: boolean;
  published
    constructor create;
    property Kunde : TKunde read FKunde write SetKunde;
    procedure Save;
    property CanSave : boolean read GetCanSave;
  end;

// Kann aus dem View heraus benutzt werden um festzustellen ob z.B. Speicherung zulässig
function TViewModelKunde.GetCanSave: boolean;
begin
  result := FKunde.IsValid;
end;

Und das Model stellet eben die Daten dar, in diesem Fall ganz schlicht.

Delphi-Quellcode:

unit Model.Kunde;

interface
uses
  System.Classes;

type
  MaxLen = class(TCustomAttribute)
  private
    FMaxLen : integer;
  public
    constructor Create(const ALength : integer); overload;
    // Per Konvention muss die Attribut-Property immer "Value" heißen
    property Value : integer read FMaxLen;
  end;

  TKunde = class
  strict private
    FName: string;
    FKdNr: integer;
    FStrasse: string;
    procedure SetKdNr(const Value: integer);
    procedure SetName(const Value: string);
    procedure SetStrasse(const Value: string);
    function GetIsValid: boolean;
  public
    property KdNr : integer read FKdNr write SetKdNr;
    [MaxLen(20)]
    property Name : string read FName write SetName;
    property Strasse : string read FStrasse write SetStrasse;
    property IsValid : boolean read GetIsValid;
  end;

implementation

{ TKunde }

function TKunde.GetIsValid: boolean;
begin
  result := (FKdNr > 0) and
            (FName <> '') and
            (FStrasse <> '');
end;

procedure TKunde.SetKdNr(const Value: integer);
begin
  FKdNr := Value;
end;

procedure TKunde.SetName(const Value: string);
begin
  FName := Value;
end;

procedure TKunde.SetStrasse(const Value: string);
begin
  FStrasse := Value;
end;

{ MaxLen }

constructor MaxLen.Create(const ALength: integer);
begin
  FMaxLen := ALength;
end;

Das ganze wird verbunden durch das Binding. Wenn ein Binding erzeugt wird mit z.b.

Delphi-Quellcode:

TEditBinding.Create(edtKdNrTest, ViewModel.Kunde, 'Text', 'Kdnr')
TEditBinding.Load

wird eigentlich nur folgendes festgelegt:

1. edtKdnrTest.Text entspricht ViewModel.Kunde.Kdnr
2. Evtl. im Model angelegte Attribute werden ausgelesen und in die UI eingetragen (Hier MaxLen)
3. Der OnExit Event wird durch einen eigenen Event überschrieben, der Original-Event wird intern gemerkt

Immer wenn jetzt der OnExit des Edit aufgerufen wird, wird zunächst der Inhalt an das Model übertragen und dann ein evtl. vorher vorhandener Original-Event aufgerufen.

Delphi-Quellcode:

procedure TCustomBinding.DoNotify(Sender: TObject);
begin
  Save;
  if Assigned(FOldNotify) then
    FOldNotify(Sender);
end;

procedure TCustomBinding.Save;
var
  AValue : Variant;
begin
  AValue := GetPropValue(FControl, FControlProp);
  SetPropValue(FBindObject, FBindProp, AValue);
end;

[Patito]

Zitat:

Zitat von Union (Beitrag 1228161)

Scheint ja wohl daran zu liegen dass es noch keiner so wirklich nutzt.

Für mich ist MVVM eher etwas, das für kleine Projekte zu komplex ist, und für komplexe Projekte zu klein.
Als ich mein GUI-Framework geschrieben habe, habe ich zuerst mit Bindings experimentiert, bin dann aber
recht schnell Richtung MVP/MVC gegangen.

MVVM neigt einfach dazu das ViewModel komplett zu overengineeren. Mit MVP mit einem richtigen Controller statt
starrer Bindings ist man einfach flexibler.

Meine Praxiserfahrung: Eine Controller Klasse ist deutlich flexibler als ein Haufen starrer Bindings.
(z.B. kennt der Controller den View und kann nach einer Eingabe den Focus einfach auf ein passendes Feld setzen
- wenn man das über das ViewModel lösen muss, muss man sich erst mal Gedanken über Focus-Status Properties machen)

Wenn man es unbedingt braucht, kann man sich in den Controller dann immer noch ein paar starrere Bindings einbauen
(ich glaube Joanna Carter hat das damals "Interactor" genannt).

[Union]

Zitat:

Zitat von Patito (Beitrag 1228192)

Zitat:

Zitat von Union (Beitrag 1228161)

Scheint ja wohl daran zu liegen dass es noch keiner so wirklich nutzt.

Meine Praxiserfahrung: Eine Controller Klasse ist deutlich flexibler als ein Haufen starrer Bindings.
(z.B. kennt der Controller den View und kann nach einer Eingabe den Focus einfach auf ein passendes Feld setzen

Eben das sollte IMHO nicht direkt passieren. Ich würde da Passive View präferieren. Herangehensweise war ja auch die Austauschbarkeit des Views. Ich will doch im Presenter so was eben nicht haben:

Delphi-Quellcode:

FView.KundenEdit.SetFocus;

Oder habe ich Dich falsch verstanden?

[mquadrat]

Das was ich aktuell in der Mache habe, entspricht so ziemlich dem, was Union geschrieben hat. Wobei ich immer noch am Zweifeln bin, ob es nicht doch irgendwie machbar wäre unsere Legacy-Anwendungen mit DSharp zusammen zu bringen. Man braucht das Rad ja nicht krampfhaft neu zu erfinden.

@Patito
Der Vorteil von ViewModels ist vor allem die Tatsache, dass man die GUI weitgehend Unit-testen kann. Der Austausch der Views wird IMHO erst interessant, wenn man X-Plattform entwickelt. Bei allem was stärkeren Wert auf das Design legt als 0815-Delphi hat man noch den Vorteil, dass das ViewModel eine verlässliche Schnittstelle zwischen Frontend-Designer und Backend-Entwickler darstellt.
Aber MVP geht sicher auch. Das war ja auch das Pattern, dass Microsoft anfangs für .NET empfohlen hat. MVVM kam da ja auch erst später auf.

@stahli
Das kann man sicher mal machen, auch wenn ich nicht glaube, dass die Lösungen da sooo unterschiedlich ausfallen werden. Delphi-Entwickler sind nun mal eben eher traditionell. Dazu kommt, dass Emba MVVM nicht wirklich promotet. Ich wäre schon froh, wenn man beim uses .* nutzen könnte (oder hab ich das Feature etwa übersehen?)

[Patito]

Zitat:

Zitat von Union (Beitrag 1228206)

Eben das sollte IMHO nicht direkt passieren. Ich würde da Passive View präferieren. Herangehensweise war ja auch die Austauschbarkeit des Views. Ich will doch im Presenter so was eben nicht haben:

Delphi-Quellcode:

FView.KundenEdit.SetFocus;

Oder habe ich Dich falsch verstanden?

Nunja, irgendwo muß dieses FView.KundenEdit.SetFocus ja rein. Es in einer abstrakten Form ins Model zu packen, ist eben oft recht seltsam. Ich bin aber auf jeden Fall auch dafür den View so passiv wie möglich zu halten.

Für die Austauschbarkeit der Views hatte ich von Anfang an immer eine Zwischenschicht drin, so dass der Presenter eben nicht direkt das Formular kennt, sondern eben nur das was der View ihm abstrahiert. Praktisch hat mir das aber eigentlich keinen Nutzen gebracht - und wenn ich nochmal von Null anfangen würde, würde ich darauf komplett verzichten.

Verschiedene Views brauchen (spätestens nach 5 Minuten im praktischen Einsatz) immer andere Models. Bei einem anderen View ist eben der Anwendungsfall immer leicht anders - dann braucht der Views vom Model bald auch leicht andere Daten, ... das driftet dann sehr schell auseinander.

Bleibt noch der Fall wo der View wirklich identisch ist (Plattformwechsel, Komponentensetwechsel).
- zur Plattformunabhängigkeit würde ich dann lieber gleich ein plattformübergreifendes Komponentenset nehmen (LCL).
- Wenn ich wirklich mal komplexe Komponenten gewechselt habe (verschiedene TreeView und Grids), habe ich mir "Interaktoren" als Abstraktionsschicht zwischen Presenter und Komponente geschrieben. Für den Presenter sehen dann z.B. in VirtualTreeView-Interactor und irgendein DevExpressTreeView-Interactor gleich aus (selbe Basisklasse).

[stahli]

Ich will das Thema nochmal hervorholen...

Bei Video2Brain ist ein Tutorial zu MVVM mit Prism unter WPF erschienen.
https://www.video2brain.com/de/video...mvvm-und-prism

WPF kann man ja sicher als das Paradebeispiel für MVVM ansehen, schließlich unterstützt es MVVM "nativ".
Wenn man dann noch ein Framework her nimmt, das nochmal alles vereinfachen soll (in dem Fall Prism), dann sollte alles easy und selbsterklärend funktionieren.

Das sehe ich aber überhaupt nicht.

Ich bin regelrecht erschrocken, was man dort alles regeln und beachten muss, damit man die eigene Anwendung in´s Laufen kriegt.

Sicher, machbar ist das, aber als Wunschlösung würde ich das nicht mal annähernd ansehen...

Wie seht Ihr das?


(Wer das Video nicht sehen kann oder will und Prim nicht selbst nutzt ist hier natürlich schon mal durch´s Raster gerutscht. ;-) )

[Sir Rufo]

MVVM hat Vorteile aber auch Nachteile. Damit muss man leben, wenn man damit hantieren will.

Warum nimmt man MVVM?

• Weil es fancy ist? - NEIN
• Weil man damit auf dicke Hose machen kann? - NEIN
• ...

MVVM ist speziell dafür gedacht, die Aufgaben der Programmierung zu teilen. Ein Team baut die GUI, ein anderes Team die BL und wiederum ein anderes Team den DAL.

Und damit das auch alles geteilt werden kann, hat man sich eben dieses MVVM ausgedacht.

Niemand hat gesagt, das MVVM Plug'n'Play ist, denn das ist es definitiv nicht. Es ist auch aufwändiger in der Implementierung. Dafür kann ich das Projekt aber aufteilen, die einzelnen Teile in sich testen und am Ende - wenn alle die Verträge eingehalten haben - alles zusammenführen und habe eine lauffähige Anwendung.

Spätere Änderungen können dann relativ einfach eingeführt werden, denn durch die strenge Entkoppelung wirken sich Änderungen in einer Schicht nicht unmittelbar auf eine andere Schicht aus. Jede Schicht kann ganz gemütlich für sich entwickelt und getestet werden.

WPF greift dem GUI-Team sehr stark unter die Arme, weil das Binding fast von selbst läuft, die anderen Teams haben davon gar nichts.

Insgesamt besteht eine Anwendung nachher nicht nur aus View-Model-ViewModel, sondern auch noch aus DTO (DataTransferObject), Services, ... (um nur ein paar Schlagworte zu verwenden.

[stahli]

Ok, das ist eine schöne und plausible Erklärung.

Für verschiedene Teams, die jeweils einzelne Projektteile bearbeiten, macht das Sinn. Das kann ich nachvollziehen.
Den Aufwand kann man dann auch verkraften und zieht insgesamt durchaus Vorteile.

Für Einzelentwickler ist das dann wahrscheinlich nicht unbedingt der sinnvollste Weg. Ich hatte das als "schöne neue Welt" angesehen (Plug&Play ist auch gut als Bezeichnung), die einfacher und bunter ist - aber das ist es dann halt doch nicht.

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1304245)

Warum nimmt man MVVM?

• Weil es fancy ist? - Ja :stupid:
• Weil man damit auf dicke Hose machen kann? - Ja 8-)
• Weil diese Art der Programmierung mal wieder Spass macht... - JA!!! :dancer:

Man(n) steht ja nicht morgens auf und überlegt sich - heute ist ein schöner Tag um mit MVVM zu beginnen...

Spätestens jedoch wenn man ein bisschen mehr Unit-Tests machen möchte, stellt man plötzlich fest - ohh doof ist ja im Formular...

Wenn man dann so vor sich hin programmiert, stellt man fest, dass die zeit bis zu einem Erflogreichen <F9> und man sieht etwas auf dem Bildschirm - deutlich länger ist... Als Clicky-Rad-Button-Coderein...

Aber die Möglichkeiten werden immer weitgehender... Und das macht einfach Spass...

Mavarik

[freimatz]

Zitat:

Zitat von Mavarik (Beitrag 1304253)

[*]Weil diese Art der Programmierung mal wieder Spass macht... - JA!!! :dancer:

NEIN!!! :pale:

Wir setzen MVVM mit Delphi seit einien jahren ein. Das Framework ist selbst gemacht. Sehr aufwendig. RTTI mit Delphi ist ein Qual.
Anderen Nachteile wurden ja schon geannt, Vorteile auch.
Unschön finde ich auch, dass man die Logik im VM suchen muss, der Anteil leigt bei uns bei gefühlt 5%

[Dejan Vu]

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen. Für Delphi würde ich das auch nicht einsetzen. Im Web-Bereich und bei WPF sieht das schon ganz anders aus.

Die Trennung von UI und BL kann man auch anders hinbekommen, da braucht's kein MVVM.

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1304266)

Zitat:

Zitat von Mavarik (Beitrag 1304253)

[*]Weil diese Art der Programmierung mal wieder Spass macht... - JA!!! :dancer:

NEIN!!! :pale:

Wir setzen MVVM mit Delphi seit einien jahren ein. Das Framework ist selbst gemacht. Sehr aufwendig. RTTI mit Delphi ist ein Qual.
Anderen Nachteile wurden ja schon geannt, Vorteile auch.
Unschön finde ich auch, dass man die Logik im VM suchen muss, der Anteil leigt bei uns bei gefühlt 5%

Mich würde mal nen grob skizziertes Demo interessieren und auch, was das Framework letztlich so macht.
Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ich seh nämlich zum Beispiel gerade nicht, wo man bei MVVM großartig mit RTTI Probleme bekommt.
Bissle Werte von a nach b schuffeln durch irgendwelche Databindings und das wars doch.

Zitat:

Zitat von Dejan Vu (Beitrag 1304285)

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen. Für Delphi würde ich das auch nicht einsetzen. Im Web-Bereich und bei WPF sieht das schon ganz anders aus.

Die Trennung von UI und BL kann man auch anders hinbekommen, da braucht's kein MVVM.

MVVM steht und fällt mit der Leichtigkeit, die Data bindings zu definieren - und selbst bei XAML kann das schonmal ziemlich komplex werden - LiveBindings sind für sowas z.B. nen ziemlicher Schuss in den Ofen.
Aber wenn man sich Angular, Knockout oder andere Vertreter anschaut, dann schaut das schon enorm schön aus, wie man seine Daten so in die entsprechenden Stellen bringen kann.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1304285)

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen.

Warum nicht? Was hat das mit einander zu tun... Mal abgesehen von VCL... VCL was war das gleich noch? Lass mich überlegen... Ach ja das alte Ding was nur für Windows ging... Bevor es FMX gab... 8-)

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304286)

Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ab wann ist den ein System / Framework ein "echtes" MVVM und wann nicht?

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304292)

Zitat:

Zitat von Stevie (Beitrag 1304286)

Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ab wann ist den ein System / Framework ein "echtes" MVVM und wann nicht?

Wenn es nach den Merkmalen von MVVM (ich liste die nun nich auf, Google kann jeder selber bedienen ;)) funktioniert und nicht nur irgendnen GUI-von-BL-Trenn-Gerät ist. Genauso wie ich nich einfach irgendwo MVC oder MVP dran schreiben kann, nur weils die Benutzeroberfläche vom restlichen Code trennt.

Und es geht dabei nicht um ein Framework sondern um die Methodik.

[QuickAndDirty]

Ich bin ja was MVVM angeht absoluter Neuling und habe mir in der Sache hier auch schon mehrfach Rat geholt.
Mittlerweile viel gelesen und auprobiert....

Es gibt viele Fragen die man für eine MVVM Aufteilng seines Projekts nicht aus der Beschreibung des MVVM Patterns entnehmen kann. Auf Vieles musste man mich erst stoßen...bzw. es wurde mal so am Rande erwähnt und ich habe mir dann zu den Schlagwörtern was ergoogelt.
Vom MFP Pattern her kenne ich solche Probleme nicht und es kann am Ende das selbe wie MVVM. In größeren Projekten habe ich dann halt zum Teil einen Haufen an Interfaces.
Der große Unterschied ist wohl, dass ich mir durch die Livebindings die Interfaces aus dem MVP spare.

Mein bisheriger Wissensstand beim Versuch das MVVM Pattern zu nutzen:
1. Die Livebindings erfordern handgeschrieben code. Irgendwie finde ich das halbgar.
2. Das MVVM Pattern existiert innerhalb eines Frameworks, so richtig selbstständig ist es nicht. Ganz anders als MVP das ja ohne Framework auskommt.
3. Das Framework ist eine sehr wichtige Sache. "Make or Buy" ist zu klären, denn Delphi liefert es nicht wirklich mit.
4. Wenn man MVVM mit nur einer View macht funktioniert es super. Wenn man mehrere benutzen möchte ist nicht ersichtlich wie die Navigation zwischen Views ins Pattern passt. Es gibt hier 2 Philosophien ViewModel-First und View-First die entscheidend dafür sind wie man die Navigation löst. daran hängt ein Rattenschwanz von Entwurfmustern wie z.B. Inversion of Control und das verwenden von Frameworks die IoC-Container mitbringen. Ich habe mich für VM-first und eine convention-over-configurtion Ansatz entschieden, was die Navigation angeht. Sprich wenn ich zu einem neuen ViewModel navigiere, spawned das "Framework" die zugehörige View (getclass ftw.). Ich weiß nicht ob das "richtiges(TM)" MVVM ist, aber nach dem ich jetzt mehrere Views und ViewModel gemacht habe, fühlt sich der code echt gut an. Ich habe den Ansatz unter dem Stichwort "Autotview" in einem VS-c#-Forum gefunden.
5. Fehler !!1 MVVM und Ansätze die die RTTI stark in Anspruch nehmen scheinen mir gegenüber MVP anfälliger für Laufzeitfehler zu sein, weil die Abhängigkeiten nicht bereits zur Compilezeit geprüft werden können. Ich will ja eigentlich möglichst schon zur Compilezeit so viele Fehler wie möglich finden!

Gibt noch genug offene Fragen für mich...
Ich speichere z.B. zurzeit den Status der Anwendung in einem Session-Objekt welches ich dann persistiere, weil die Navigation auf VM-Ebene stattfindet und ich diese Informationen nicht umständlich von VM zu VM zu VM zu dessen Model-Object übertragen möchte. Mir gefällt das so, aber das Pattern sagt nichts dazu. Klar das Modelobject könnte ja auch für alle VMs das selbe sein. Das habe ich halt in die Session ausgelagert.

Ich nutze diesen thread einfach mal in der Hoffnung, dass mir jemand sagt ob ich soweit richtig liege.

[Stevie]

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

Fokus hab ich bei dem Prototypen auf das deklarative Databinding und ein bisschen Dependency Tracking gelegt. Alles was darüber hinaus geht, hab ich erstmal außen vor gelassen - für mich steht und fällt eine MVVM Lösung mit der einfachen Handhabung der V-VM Bindung.


https://bitbucket.org/sglienke/simplemvvm

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304353)

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

OK... Das sieht für mich alles aus als wäre es nicht wirklich mehr Delphi :stupid:

Es funktioniert - das ist schon mal gut...
Würdest Du nicht normalerweise den Code des ViewModels in einen andere Unit packen?

Abgesehen davon, das jeder klick auf das Formular den Code zerstört...

Gibt es irgendwo ein Tutorial was alles mit den Attributen geht...

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Zitat:

Zitat von Stevie (Beitrag 1304353)

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

OK... Das sieht für mich alles aus als wäre es nicht wirklich mehr Delphi :stupid:

Wenn du damit meinst, dass das Form nicht mit Eventhandlern vollgestopft ist, dann seh ich das mal als positiv an.

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Es funktioniert - das ist schon mal gut...
Würdest Du nicht normalerweise den Code des ViewModels in einen andere Unit packen?

Na logisch, deshalb schrieb ich ja auch *zusammengeklatscht* :stupid:

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Abgesehen davon, das jeder klick auf das Formular den Code zerstört...

Bei mir nicht, neue Komponenten oder Eventhandler können schön hinzugefügt werden ohne dass was kaputt geht (sowohl in XE, XE7 und XE8 keine Probleme).

[stahli]

@Stevie

Ich habe mir das Projekt mal angesehen.
Also dass das mit den Attributen so funktioniert ist schon beeindruckend. Auch das Ergebnis ist nicht schlecht.

Aber für meinen Geschmack bestehen da zum Einen sehr viele Abhängigkeiten und man muss genau wissen, was man tut.

Die Interfaces und anonymen Funktionen sind nichts für Laien sondern eher für Fortgeschrittene.
Wenn man an einer Stelle etwas nicht richtig macht, spielen die Gruppen nicht mehr zusammen.

Ich habe mal testweise das LastName-Edit in eine andere Groupbox verschoben und das Programm ließ sich nicht mehr kompilieren.
Zurücksetzen in die Originale Groupbox half auch nicht mehr.

(Ich wollte die Quellen nochmal neu auschecken, hatte aber dann Angst, dass ich meinen Murks statt dessen hochlade... und hab es lieber gelassen.)


Also mein Eindruck: Interessant, dass und wie es funktioniert hat.
Aber es setzt fortgeschrittene Fähigkeiten allgemeiner Art (Interfaces, Generics, Attribute, anonyme Methoden) und der Funktionalität des Frameworks voraus.


Würdest Du Dich Sir Rufo anschließen, dass es nicht wirklich eine Vereinfachung der Programmierung allgemein sondern eher eine Lösung zur Aufgabentrennung für mehrere Teams ist?

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1304405)

Wenn man an einer Stelle etwas nicht richtig macht, spielen die Gruppen nicht mehr zusammen.
Ich habe mal testweise das LastName-Edit in eine andere Groupbox verschoben und das Programm ließ sich nicht mehr kompilieren.

(Ich wollte die Quellen nochmal neu auschecken, hatte aber dann Angst, dass ich meinen Murks statt dessen hochlade... und hab es lieber gelassen.)

... ich werd doch nicht jedem Schreibzugriff auf mein Git repo geben ;)

Die Groupboxen haben rein gar nix mit der Funktionialität zu tun, sondern dienen der optischen Abgrenzung, ich hätt auch alles so auf die Form klatschen können.

Zitat:

Zitat von stahli (Beitrag 1304405)

Also mein Eindruck: Interessant, dass und wie es funktioniert hat.
Aber es setzt fortgeschrittene Fähigkeiten allgemeiner Art (Interfaces, Generics, Attribute, anonyme Methoden) und der Funktionalität des Frameworks voraus.

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt. Außerdem ist das ein Prototyp, wo ich mich um Fehlermeldungen, Validierung und dergleichen nicht geschert habe.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304407)

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt.

Ja, ja, ist aber schon hohe Schule, oder?

Die Bindings sind echt trickreich, aber ich finde das ist nicht wirklich lesbarer Code... Dann habe ich doch lieber ein bisschen mehr code im Formular und sehe, dass die Edit1... eine OnChange hat... und in der OnChange kann ich dann den Code reinbringen der alles nötige mit den Bindings macht.

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304410)

Zitat:

Zitat von Stevie (Beitrag 1304407)

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt.

Ja, ja, ist aber schon hohe Schule, oder?

Keine Ahnung, für mich sind Generics, anonyme Methoden, RTTI und dergleichen so alltäglich wie nen TButton - obwohls die erst seit über ner halben Dekade gibt ;)

Zitat:

Zitat von Mavarik (Beitrag 1304410)

Die Bindings sind echt trickreich, aber ich finde das ist nicht wirklich lesbarer Code... Dann habe ich doch lieber ein bisschen mehr code im Formular und sehe, dass die Edit1... eine OnChange hat... und in der OnChange kann ich dann den Code reinbringen der alles nötige mit den Bindings macht.

Da trennen sich wohl unsere Meinungen, was lesbarer Code ist. Ich mag deklarativen Code, ich kann mit einem Blick sehen, welche Eigenschaft in dem edtFirstName angezeigt wird und ich muss mich nicht durch den OI hangeln, oder in der dfm rumsuchen, um zu sehen, wo irgendnen Binding verknüpft ist. Was würde denn in dem OnChange stehen? viewModel.FirstName := edtFirstName.Text? Oder firstNameBinding.Update oder sowas? Und wie kommen die Eigenschaften, die sich im VM geändert haben, wieder in die View?

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304411)

Und wie kommen die Eigenschaften, die sich im VM geändert haben, wieder in die View?

Das VM lösst ein Property Change Multicast Event aus und alle Views die auf das Feld/Record/ViewGruppe hören aktualisieren sich...