This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: WPF Teil 3: Das Softwaredesign will gut überlegt sein
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Im letzten Beitrag wurde die Frage geklärt, wann denn eine Umsetzung mit Hilfe der Windows Presentation Foundation als sinnvoll erscheint und in welchen Fällen dann doch zu den herkömmlichen Windows Forms gegriffen werden soll. Ist eine Entscheidung zugunsten der WPF gefallen, müssen einige Vorarbeiten erledigt werden. Unter anderem betrifft dies das Design der Software selbst. Einige Verhaltensweisen sind dann doch unterschiedlich, was sich unter anderem auch im Softwaredesign auswirkt. Nachfolgend werden diesbezüglich einige Varianten vorgestellt als auch einige allgemeine Punkte behandelt.
Bietet die WPF bereits ein entsprechendes Konzept?
In die Windows Presentation Foundation wurde einiges an Funktionalität und viele neue Konzepte hineingepackt. Auch für das Softwaredesign wurde etwas getan. So ist es wichtig, Businesslogik von der Darstellung zu trennen. Dies wird mit Hilfe der WPF-Commands ermöglicht. Wie der verlinkte Artikel zeigt, stehen mehrere Varianten zur Verfügung. Mal enger mit der UI gekoppelt, mal davon losgelöst.
Für kleinere Projekte mag dies durchaus eine gute Wahl darstellen. Für größere Projekte (beispielsweise von Anwendungen mit einigen Mannmonaten Aufwand) meine ich, dass dieses Konzept nicht vollkommen taugt. Hier bedarf es einer größeren und besseren Lösung.
Das Model-View ViewModel Pattern
Eine wesentlich bessere Lösung wird uns hier mit dem Model-View ViewModel in die Hand gelegt. Es ist dies eine Variante des Model-View-Controller Patterns.
Dies sieht auf den ersten Blick möglicherweise etwas verwirrend aus, tatsächlich gestaltet sich die Verwendung jedoch nicht schwierig. Im Gegensatz zum MVC wird der Controller hier mit einer ModelView ausgetauscht (wobei im Hintergrund weiterhin auch ein Controller seinen Dienst tun kann). Die ModelView besitzt eine enge Kopplung zur View -> DataBinding. Dadurch kann die UI auf sehr einfache Weise aktualisiert werden. Diese enge Bindung muss jedoch nicht an das Model weitergegeben werden. Letzteres hält die einzelnen Entities.
Durch die Trennung in diese einzelnen Bestandteile ist es nun möglich, Daten- und Geschäftsklassen vom User Interface zu trennen. Der Vorteil besteht darin, dass die gesamte Anwendungsarchitektur dadurch flexibler, austauschbarer und vor allem testbarer wird.
Zu diesem Thema gibt es eine Serie von Dan Crevier welche ich dem Leser nicht vorenthalten möchte:
Im WPF-Umfeld stehen derzeit nicht mehr wirklich andere Patterns für die Kommunikation zwischen dem User Interface und den darunter liegenden Schichten zur Verfügung. Natürlich muss hier erwähnt werden, dass selbst das MVVM Anpassungen erfahren kann und im Laufe der Entwicklung an einer eigenen Lösung auch erfahren wird.
Es empfiehlt sich jedoch auf jeden Fall, alle Anforderungen zu definieren und daraus weitere mögliche Patterns, die innerhalb des MVVMs zum Zuge kommen abzuleiten.
Fazit
Immer, wenn neue Technologien oder Konzepte ins Spiel kommen, müssen neue Mittel und Wege gefunden werden, ein Projekt erfolgreich abzuschließen. Das MVVM ist ein erster Schritt in die richtige Richtung. Mit Fortbestand der WPF werden weitere Lösungen, Abwandlungen des MVVMs und weitere Verbesserungen auf uns Entwickler zukommen.
Grundsätzlich empfehle ich, das erwähnte Pattern in kleinem Rahmen zu testen und einen kleinen Prototyp zu entwickeln, um ein erstes Gefühl zu bekommen. Darauf aufbauend können anschließend die ersten ernsthaften Anwendungen entwickelt werden.
Tipp: Setzen Sie sich mit den Eigenheiten der WPF auseinander, um vor unliebsamen Überraschungen geschützt zu sein. Gerade wenn unbekannte Patterns das erste Mal eingesetzt werden, kann es sehr leicht zu Designfehlern kommen, die im weiteren Zuge größere Umstellungen/Refactorings notwendig machen.
Previous Topic
;)