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.