Die meisten aktuellen Silverlight oder WPF Projekte sind zum Glück nach MVVM umgesetzt und so erhalten die Views ihre Daten aus den jeweiligen ViewModels. Um dann richtig designen zu können ist es unumgänglich mit Design Time Sample Data zu arbeiten. Denn nur dann ist es wirklich möglich, in Expression Blend oder dem Designer von Visual Studio zu arbeiten, ohne nach jeder Änderung das Projekt bauen und starten zu müssen. Leider wird das in vielen Projekten unterschätzt und der Weg, um ein Design zu prüfen, führt unweigerlich über das Starten und Navigieren innerhalb der Anwendung (was in den seltensten Fällen schnell geht).
Eine Lösung für dieses Problem bietet Blend von Haus aus an: Sample Data. Diese sollen dem Anwender auf möglichst einfache und schnelle Weise die Möglichkeit geben, zur Designzeit (also entweder in Blend oder dem Visual Studio Designer) die datengebundenen Controls mit Content zu befüllen. In der Theorie (oder bei einfachen bzw. kleinen Projekten) funktioniert dieses Verfahren auch sehr gut. Blend kann beispielsweise aus den ViewModel Klassen Sample Data generieren und legt dafür eigene .xaml Dateien in dem Ordner "SampleData" an. Der große Vorteil ist, dass der Anwender im Idealfall keinen Mehraufwand hat, da Blend auf Basis der public Properties und der Typen automatisch Daten erzeugt.
So werden z.B. string Properties durch "Lorem ipsum" gefüllt und DateTime Properties mit zufälligen Daten. Selbst komplexe Typen werden nachgebildet:
Dieses Verfahren hat allerdings auch entscheidene Nachteile (gerade in realen Projekten wichtig):
- In jedem Projekt mit Sample Data wird ein neuer Ordner inkl. verschiedener .xaml Dateien erzeugt
- Man hat ohne weiteres keinen Einfluß auf die erzeugten Daten
- Eine einfache Aktualisierung der Daten / Klassenstruktur ist nicht möglich (Diese müssen neu erzeugt werden)
Eine Idee zu einer Alternative möchte ich daher hier gerne vorstellen: Um vollständige Kontrolle über die Beispieldaten zu erhalten ist es notwendig, diese selber zu erstellen. Um darüberhinaus noch die Möglichkeit des einfachen Refactorings bzw. Aktualisierung zu bekommen, ist die Idee, eine eigene Klasse für die jeweiligen Daten zu erzeugen. Hat man beispielsweise ein ViewModel, so kann man eine neue Klasse von diesem ViewModel ableiten und die entsprechenden Properties mit Daten füllen bzw. sinnvoll initialisieren.
Auf der linken Seite ist das original ViewModel zu sehen, auf der rechte Seite die abgeleitete Klasse mit den Beispieldaten. Dort werden exemplarisch zwei Möglichkeiten verwendet, um die Properties mit Daten zu befüllen: Im Konstruktor oder als Überschreibung der Property.
Wenn man jetzt allerdings die original Klasse refactored und z.B. eine Property umbenennt, so wird das Sample Data ViewModel direkt mit angepasst. Außerdem hat man jetzt die Möglichkeit alle Daten selber zu bestimmen und beispielsweise auch mal lange Namen oder Sonderzeichen auszuprobieren.
Um die neue Klasse im Designer zu verwenden ist lediglich folgende Zeile Code in der View notwendig:
Das Attribut "IsDesignTimeCreatable" muss dabei auf jeden Fall auf "True" stehen, damit die Klasse (und damit auch der parameterlose Konstruktor) durch den Designer aufgerufen wird.
Einen entscheidenen Nachteil hat dieses Vorgeher jedoch: Wie beim Erzeugen von zusätzlichen .xaml Dateien durch Blend, werden auch hier die Projekte durch weitere Dateien/Klassen "aufgebläht". Wem das egal ist, der braucht jetzt nicht weiterzulesen ;-)
Für alle anderen habe ich noch einen kleinen "Trick", um diese Sample Data Klassen zu verstecken. In der .csproj Datei eines Projektes kann man Abhängigkeiten definieren:
So kann man erreichen, dass die abgeleiteten ViewModels in Visual Studio (und in Blend) hinter den jeweiligen originalen ViewModels "versteckt" werden:
Leider ist mir bisher nur die Möglichkeit bekannt, die Abhängigkeit manuell in der .csproj Datei einzutragen, aber vielleicht gibt es auch dafür Extensions (z.B. ReSharper, VS Commands etc.)?!
In einem zweiten Teil (kommt später) möchte ich noch eine weitere, alternative Idee zu Beispieldaten vorstellen, die genau den 3. Kritikpunkt (zusätzliche Dateien in den Projekten) addressiert.
Wichtig dabei ist das "new" Keyword bei der DependencyProperty und dem Property Wrapper. Außerdem reicht es nicht, nur die Property zu überschreiben, es muss die komplette DependencyProperty sein.
Einfach nur gesetzter Stroke auf dem dunklen Hintergrund-Element: 
Wie man sieht, lässt es WPF (und auch Silverlight) zu, doppelte Setter im Style zu verwenden, ohne eine Fehlermeldung zur Design- / Laufzeit zu schmeißen. Das Verhalten ist dadurch allerdings nicht mehr eindeutig korrekt. Zur Laufzeit (und im Designer) überschreibt der letzte Setter den Wert der Property. Wenn man nun aber z.B. über Blend die Property ändert, so ändert Blend den Wert des ersten Setters, was augenscheinlich keine Auswirkungen auf das Ergebnis hat. Die Verwirrung ist umso größer, wenn in diesem Fall über Blend eine Resource an die Property gebunden wird. Blend zeigt nun einen gelben Rahmen um die Property (was bedeutet, dass diese gebunden ist), allerdings hat das keine Auswirkungen auf das Ergebnis, weder im Designer, noch zur Laufzeit. FAZIT: Steht man mal wieder vor dem Rätsel, warum ein Binding in einem Style nicht funktioniert, einfach mal im XAML Code runterscrollen und überprüfen, ob es einen doppelten Setter gibt ;-) UPDATE: In Silverlight bekommt man zumindest eine Fehlermeldung in Blend, wenn man versucht den Style erneut zu öffnen. Allerdings lässt sich das Projekt trotzdem kompilieren und ausführen (mit dem gleichen Ergebnis, wie oben beschrieben). 