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