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.
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.
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).
- 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
Fertig