MVVM in Windows 8!?

Wer mich kennt, weiß, ich bin Pragmatiker. Meine Begeisterungsfähigkeit für 3 oder 4 Buchstaben Akronyme ist über die Jahre deutlich gesunken. Technologie muss dem Benutzer (wie der Name schon sagt) nützlich sein. Programmiersprachen müssen dem Entwickler dienen und ihn nicht umerziehen. Ich weis, viele der fortgeschrittene Developer wünschen sich nichts anderes, wenn sie fremden Code bearbeiten müssen. Ich kann aus dieser Sicht MVC, MVP und auch MVVM als Entwurfsmuster genauso viel abgewinnen wie Blümchentapeten.

Wenn ich einen Doppelklick auf einen Button mache und den so erzeugten Eventhandler mit drei Zeilen Code fülle, kann ich beim besten Willen nichts bösartiges daran erkennen. Ein iCommand ist in den meisten Fällen ungleich aufwändiger zu bauen.

ingosJa ich höre schon, TDD. Softwaretest und Qualität. Ist ja auch gar nichts dagegen zu sagen. Nur per CommandBinding lässt sich eine UI automatisiert testen. Doch halt, Switchback zu Lebensrealität. UI’s lassen sich nicht automatisiert testen, das ist eine Illusion. Ich selbst habe mich schon mit einer Taschenlampe den Lichtsensor penetrieren sehen und Ingo Rammer zeigt auf Facebook die Simulation eines Mobile Verbindungsabruches per Mikrowelle.

Das viel wichtigere Argument ist meiner Meinung nach, der Fast&Fluid Ansatz von Windows 8 METRO Styled APPs. Daraus ergibt sich, das alles was etwas länger brauchen könnte (50ms),  asynchron laufen muss.

Dabei ergibt sich die interessante Problemstellung, da das UI schneller gezeichnet ist, als die Daten eigentlich ankommen. Genau hier setzt das Observer Pattern ein. Ein Objekt kann seiner Darstellung (dem View) mitteilen, das es sich geändert hat. Dafür gibt es nicht nur in Windows 8 sondern auch WPF und Silverlight passende Klassen wie ObservableCollection oder das Interface INotifyPropertyChanged.

Wenn man damit eine Liste erstellt und in XAML bindet fühlt sich das ganz natürlich an. Damit ist der XAML Part der View und das Listen Objekt das ViewModel. Daran führt in Windows 8 METRO Anwendungen eigentlich kein sinnvoller Weg vorbei.

Also die Antwort ist ganz klar. MVVM ist in Windows 8 METRO Anwendungen ein muss, weil es die Arbeit für den Entwickler einfacher macht. Wie immer geben Entwurfsmuster keine konkrete Implementierung vor. Dies obliegt der Verantwortung der Entwickler. Also ob z.B. iCommand verwendet wird, sehe ich nicht als gesetzt.

Kommentare (2) -

  • Mir gefällt der Ansatz der ICommands ausgesprochen gut. Ich schätze u.a. deren Eigenschaft, das das Kommando automatisch (de)aktiviert wird. Dabei ist es egal, an wie vielen Stellen es verwendet wird (Button, MenuItem, ContextmenuItem, Shortcut). Dies ist aus meiner Sicht nur ein kleiner Vorteil, den man durch die Implementierung à la MVVM erreicht. Ein weiterer, aus meiner Sicht unschätzbarer Vorteil, ist die Arbeit mit Designtime-Objekten. Ich finde es ungeheuer hilfreich, mir schnell ein DesignTime-ViewModel zu erstellen und meine UI dann gefüllt mit Daten gestalten zu können.

    Just my 2 cents.
  • Hallo Hannes,
    ich sehe es genau anders:
    Solange der Doppelklick auf den Button in die Codebehind Datei führt, was ja seit alten VB Zeiten der Fall ist, wird Software nicht wartbar (maintainable) und weiterentwickelbar (evolvable) sein, sondern immer eine Quick-und Dirty Lösung bleiben.
    Ich denke, vor allem Schülern, also neue Entwickler, sollte man gar nicht erst diese altbackene Programmiertechniken beibringen.
    Es ist doch ganz logisch, dass man Ordnung im Code besser verwalten kann, wenn man modular denkt und die Belange (Concerns) trennt.

    Das Problem ist nur, dass die Entwickler von Microsoft selbst so altbacken entwickeln.
    WPF, Silverlight, Silverlight für WP7 und nun WinRT ... es gibt Funktionalitäten, die gar nicht ohne Codebehind laufen.

    Warum nur, setzt Microsoft in all den WinRT metro app Beispielen wieder nur auf Codebehind, wo sich Millionen per Copy und Paste ihre Anwendungen zusammenklicken?

    Warum ist z.B. ein MVVM Framework nicht fester Bestandteil vom NET und jetzt auch vom WinRT Framework? PRISM wird für NET 4.5 irgendwann als AddOn nachgeliefert, für WinRT scheint es gar nicht geplant zu sein. Stattdessen muss die Community mit den bekannten MVPs mit eigenen Frameworks einspringen.

    Noch mal: SoC sollte ein festes "Denkmuster" eines jeden Entwicklers von Anfang an sein. Und ja, man muss die Entwickler zu ihrem Glück zwingen und Codebehind per Warnmeldung verbieten Wink

    Grüße
    Dirk

Kommentar schreiben