Frage zum Designkonzept MVVM unter Delphi

[Schokohase]

Schau dir mal in Ruhe die Beispiel-Anwendung an.

Nochmal, wenn du Fragen hast, dann stelle diese bitte konkret und nicht so nebulös wie "bei Desktop müsste ich evtl. noch die Netzwerk-Domain angeben" oder "bei WebSite muss ich womöglich einen Server auswählen".

Darauf kann ich nur antworten: "Evtl. müsstest du ...". Wenn du noch nicht weißt was du programmieren musst, wie willst du es dann programmieren? Aber evtl. beantwortet der AuthenticationService deine Frage.

Diese reine Lehre von MVVM passt eigentlich auf einen Bierdeckel. Also leg mal deine Ehrfurcht vor MVVM ab und schau dir an was es ist. Es sagt dir eigentlich nur: Trenne die bunten Lichter von den Fakten und den Faktenfindern.

Die Frage "Warum macht man MVVM?" kann man nur im Kontext beantworten.

Kontext Delphi (VCL, FMX): Macht man nicht (es sein denn man hat ganz viel Langeweile und keine Angst davor wen es doch nicht klappt)
Kontext WPF, UWP, Xamarin, ...: Weil diese Frameworks direkt auf MVVM zugeschnitten wurden.

[Rollo62]

Ich schau mir das Beispiel noch an, habe ich ja geschrieben ...

Das MVVM auf einen Bierdeckel passt glaube ich auch nicht.

Ich will weder ketzterisch noch ehrfürchtig klingen, anscheinend versteht man mich nicht ganz.
Nur denke ich MVVM hat wie Alles in der Welt mehrere Seiten, und man sollte nicht unbedingt immer Bibelartig dran halten.

Das Beispiel unten war genau das, nicht etwa das ich nicht definieren kann was mein Projekt können soll.
Meistens definiert das PROJEKT was ich machen muss (mein Kunde, geänderte Infrastruktur, Apple/Google/MS Updates, etc.), so dass solche Fragen wie unten sicher auftauchen.

Konkreteres Beispiel:
Ich habe eine App mit speziellem Login für EINEN User gleichzeitig.
Der Kunde verlangt nach einem Jahr das sich, weil MEHRERE User gleichzeitig den Rechner teilen, sich mehrere User gleichzeitig anmelden und arbeiten können.
Wo wird da was wohin gelegt, und wie ist die Transition von Version 1 zu Version 2 im produktiven Betrieb ?
Hat das MVVM für einen User noch viel mit dem MVVM für mehrere User zu tun ?
Was muss ich mit dem BusinessModel machen ?
Dinge können sich eben verändern.

Was wäre denn die Antwort darauf ?
Meine wäre bei Anforderungsänderungen rigoros reworken, auch wenns weh tun kann.

Ich will Sir Rufos Lösung nicht verteidigen, aber es ist auch EINE mögliche Implementiereng: Why not ?

Jetzt höre ich aber lieber auf damit, denn das bringt uns ja nicht weiter.

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Ich schau mir das Beispiel noch an, habe ich ja geschrieben ...

Das MVVM auf einen Bierdeckel passt glaube ich auch nicht.

Ich habe dir doch MVVM mit einem Satz erklärt, der passt auf einen Bierdeckel.

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Ich will weder ketzterisch noch ehrfürchtig klingen, anscheinend versteht man mich nicht ganz.
Nur denke ich MVVM hat wie Alles in der Welt mehrere Seiten, und man sollte nicht unbedingt immer Bibelartig dran halten.

MVVM sagt einfach nur etwas über die Trennung (Bunte Lichter, Fakten, FaktenFinder) aus. Wenn du es nicht mehr trennst, dann ist es kein MVVM mehr.

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Konkreteres Beispiel:
Ich habe eine App mit speziellem Login für einen User.
Der Kunde verlangt nach einem Jahr das sich, weil mehrere USer den Rechner teilen, sich mehrere User gleichzeitig anmelden können.
Wo wird da was wohin gelegt, und wie ist die Transition von Version 1 zu Version 2 im produktiven Betrieb ?
Dinge können sich eben verändern.

Was wäre denn die Antwort darauf ?
Meine wäre bei Anforderungsänderungen rigoros reworken, auch wenns weh tun kann.

Das passiert bei MVVM auch. Aber eben schön getrennt voneinander (MVVM sei Dank).

1. AuthenticationService
   Anpassen/Erweitern des Interfaces um die neuen Anforderungen erfüllen zu können (z.B. wird jetzt Domain, Username, Password benötigt)
2. ViewModel
   Hinzufügen der Eigenschaft Domain und beim Login verwenden
3. View
   Ein zusätzliches Edit-Feld einfügen und mit der Domain-Eigenschaft vom ViewModel binden

Fertig

[Rollo62]

Zitat:

Das passiert bei MVVM auch. Aber eben schön getrennt voneinander (MVVM sei Dank).

AuthenticationService
Anpassen/Erweitern des Interfaces um die neuen Anforderungen erfüllen zu können (z.B. wird jetzt Domain, Username, Password benötigt)
ViewModel
Hinzufügen der Eigenschaft Domain und beim Login verwenden
View
Ein zusätzliches Edit-Feld einfügen und mit der Domain-Eigenschaft vom ViewModel binden

Du vergisst aber das sich hier womöglich auch das BusinessModel ändern muss.
Also sind die Trennlinien M-V-VM schwimmend bei Anforderungsänderungen, und ich muss doch in Allen Teilen was anpassen.
Nach dem Motto "wie mans macht macht mans falsch".

Jetzt höre ich aber wirklich auf :stupid:

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413897)

Also sind die Trennlinien M-V-VM schwimmend bei Anforderungsänderungen, und ich muss doch in Allen Teilen was anpassen.

Wieso sind die Trennungslinien schwimmend? Alles ist doch schön separiert voneinander und kann auch unabhängig voneinander erfolgen.

Aber wenn ich dem Anwender eine neue Information präsentieren will, dann hat das (oh welch ein unerwartetes Wunder) Auswirkungen auf alle Bereiche.

Die View muss es anzeigen, das ViewModel stellt es für die View zur Verfügung, das Model (hier z.B. der AuthenticationService) muss es beschaffen oder verarbeiten.

MVVM sagt nur: TRENNE DEINEN KRAM. Es ist nicht die Bibel oder die heilsbringende Lösung für alle deine Probleme.

[freimatz]

Amen. :-D

[Stevie]

Zitat:

Zitat von Schokohase (Beitrag 1413898)

MVVM sagt nur: TRENNE DEINEN KRAM.

MVVM spezifiziert schon recht genau, wie man den Kram trennt - nur weil man Kram trennt, macht man noch lang kein MVVM.

[Schokohase]

Zitat:

Zitat von Stevie (Beitrag 1414000)

Zitat:

Zitat von Schokohase (Beitrag 1413898)

MVVM sagt nur: TRENNE DEINEN KRAM.

MVVM spezifiziert schon recht genau, wie man den Kram trennt - nur weil man Kram trennt, macht man noch lang kein MVVM.

Ja, das habe ich ja auch weiter oben ausgeführt und hier nochmal auf eine verkürzte Aussage heruntergebrochen, weil immer noch zuviel in dieses MVVM hineininterpretiert wurde.

Ganz stark heruntergebrochen heißt MVVM: Trenne deinen Kram.
Ganz stark heruntergebrochen heißt ISO9000: Dokumentiere deinen Kram.

BTW:

Zitat:

Zitat von Stevie

Brrrr, das ist doch kein MVVM, was Sir Rufo da geschrieben hat. Viel zu viel Code in der View.

Die Menge des Codes in der View entscheidet nicht ob MVVM-konform oder nicht, nur womit sich dieser Code befasst. Ist der Code rein auf die Kommunikation mit dem Benutzer beschränkt (bunte Lichter, Drag´Drop,...) dann ist das immer noch MVVM.

Ich lasse mich auch gern vom Gegenteil überzeigen anhand eines DragˋDrop Beispiels

[Stevie]

Ich zitiere mal Wikipedia (nicht weil Wikipedia immer recht hat, sondern weil das ein Kernpunkt von MVVM ist - wie ich auch bereits zuvor erwähnte. MVVM ohne Databinding ist kein MVVM).

Zitat:

Das MVVM-Muster kann als technologie-spezifisch bezeichnet werden, da für die Verknüpfung von View und ViewModel ein Datenbindungsmechanismus benötigt wird. Diese Infrastruktur wird häufig als Binder bezeichnet. Im Detail handelt es sich hierbei um einen bidirektionalen Einsatz des Beobachter-Musters. Binder, welche eine Datenbindung auf Basis von deklarativen Angaben etablieren können, sind für verschiedene Techniken vorhanden.

Und im Code aus Beitrag 1 und bei vielen anderen als MVVM bezeichneten Implementierungen sehe ich das nicht.
Ich poch da nur so drauf, weil es schon zu viele Delphi Entwickler gibt, die irgendwas MVVM nennen, was keins ist (oder was sie "für MVVM halten")

Zitat:

Zitat von Schokohase (Beitrag 1414002)

Ich lasse mich auch gern vom Gegenteil überzeigen anhand eines DragˋDrop Beispiels

Brauch ich nicht, hab schon gesagt, dass MVVM in Delphi imho Tinnef ist.

[jus]

Vielen Dank für die vielen Anregungen. :-)

Zitat:

Zitat von mkinzler (Beitrag 1413852)

Die Begrifflichkeit des MVVM wird tatsächlich in fast jeder Lösung verschieden interpretiert.
Mir gefällt der Ansatz von grijjy

Bin mit der Erweiterung allerdings noch nicht wirklich weit gekommen.

Würde mich aber um Mitstreiter freuen. (Gerne auch bessere Porogrammierer wie ich).

Den Hinweis von mkinzler mit grijjy hätte ich mir auch gerne angeschaut, es ließ sich mit meiner alten Delphi 2007 Version nicht kompilieren.

Ich denke, dass ich zwar das Konzept von MVVM in Groben verstanden habe, aber vermutlich habe ich es nicht so gut verstanden, dass ich die konkrete Implementierung in Delphi hinbekomme. Ich würde mich halt viel einfacher tun, wenn ich eine einfache funktionierende Delphi Source hätte, wo ich mich halt weiterhanteln kann. Und nun meine ketzerische Frage, da wir bisher öfters schon gehört haben, was nicht MVVM ist. Kennt wer eine simple Delphi MMVM Beispielimplementierung mit Source, die ohne mächtiges Framework und Live-Binding auskommt? :duck: