Frage zum Designkonzept MVVM unter Delphi

[Schokohase]

Also zu jeder View gibt es ein ViewModel.

Wenn die Desktop-View und Mobile-View gleich sind, dann ist auch das ViewModel gleich.
Wenn nicht ...

Der Business-Layer besteht idR aus Services, die dem ViewModel per Konstruktor-DI übergeben werden. Hier bietet sich somit auch ein DI-Container an. Also es wird nicht das ViewModel an das Model übergeben, sondern das Model an das ViewModel.

Update
Wer sich dafür interessiert kann sich ja mal ein echtes Beispiel anschauen, wo MVVM verwendet wurde. Da kann man sehr viel von lernen.

SmartHotel360 - Connect(); 2017 keynote demo apps

Und hier als Beispiel das LoginViewModel und die zugehörige LoginView (CodeBehind) (da sehen wir minimalen Code ... aber der ist nur für die Anzeige)

[jus]

Hallo,
ich gebe zu dass in dem Beispiel von Sir Rufo kein Model vorhanden ist, aber ich denke, das zu erweitern ist nich so schwer.
Aber wie würdet ihr das Beispiel ändern, damit es MVVM konform wird?

[Rollo62]

Zitat:

Du darfst das so sehen, aber bitte nenne das nicht MVVM. Danke.

Was genau war an der Beschreibung denn so falsch ?

@Schokohase
Ja endlich mal ein richtiges Projekt, leider finde ich da unter Delphi kaum etwas.
Leider bin ich ungerne auf C# und Java, aber da gibt es natürlich mehr reale Projekte,
ich werde mir deinen Link morgen etwas tiefer anschauen.

Aber nehmen wir daraus nur mal Z.B. den LoginView:
- bei Mobile as is
- bei Desktop müsste ich evtl. noch die Netzwerk-Domain angeben
- bei WebSite muss ich womöglich einen Server auswählen

Also wären M- und D-View unterschiedlich, dementsprechend M- und D-ViewModel unterschiedlich.
Oder kann man ein Basis-ViewModel für alle Fälle definieren, und nur Ableitungen in M- D- W- bilden ?
Müssten dann etwa auch die BusinessModels unterschiedlich sein ?
Oder sollte das BusinessModel Alle Fälle unterstützen und die VieModels federn das ab ?

Ja es ist schon spät und das ist vielleicht etwas an der Haaren herbeigezogen,
aber das wäre meine grundsätzliche Fragestellung zu dem Ganzen Thema.
Was sagt denn die reine Lehre dazu ?

Ich sehe eben Fälle wo die reine Lehre an ihre Grenzen stoßen kann, und kann mich dann damit auch zufrieden geben.
Statt die 99% Perfekt auf 100% zu hieven, reichen mir manchmal eben 95% (3-Sigma) auch noch aus

Wäre nett da mal was Konkretes zu lesen, wie vom Schokohasen, und nicht nur das Übliche "ich würde das nicht MVVM nennen" abzuspulen.
Ich kann es auch "n-Tier Model-View" oder "Otto" nennen, und lasse das Ganze MVP, MVVM, MVC, M* Gedöns mal aussen vor.

Es geht doch immer um Erreichung gewisser Ziele, die manchmal diametral gegeneinanderstehen.
Modularisierung, Entkopplung, Testbarkeit, Codequalität, Lesbarkeit, Lernkurve, Automatisierbarkeit, Teamarbeit, Komplexität, Redundanz, Flexibilität, Time-to-Market, LOC, Kompatibilität, etc. etc. etc.
Keiner macht MVVM nur weil es so sagenhaft cool ist.

Zitat:

Aber wie würdet ihr das Beispiel ändern, damit es MVVM konform wird?

Ich denke MVVM und der ganze M* Kram sind nicht in Stein gemeisselt, sondern können durchaus diverse Implementierungen haben.
Mir gefällt die Lösung unten auch nicht besonders, aber Sir Rufo ist da sicher auch kein Anfänger.
Diese Lösung greift gewisse Ziele auf und löst diese, aber eben nicht Alle (sofern das überhaupt geht).

Da ist mir Delphi eine pefekte, saubere Lösung leider immer noch schuldig geblieben.
Alle die finden das ich hier Quatsch rede können mich gerne Überzeugen und eines Besseren belehren

Rollo

[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 von Rollo62:

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 von Rollo62:

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 von Rollo62:

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

Rollo