Eine Frage, die mir immer wieder gestellt wird ist, "Wie strukturiert man größere WPF Projekte?". Diese Frage muss man zunächst mal eingrenzen - geht es um die Architektur (Programmstruktur) oder um die Strukturierung der WPF spezifischen Assets (Controls, Styles, Bilder etc). Das ist eine Frage, die vor allem auch für Designer relevant ist.
Architektur
Die Frage nach der Architektur lässt sich sicher nicht ad-hoc beantworten. Es gibt Referenz-Architekturen wie Composite WPF (Prism) für Composite Smart Clients (Business Anwendungen, die sich aus verschiedenen unabhängigen Teilen zusammensetzen) oder Entwurfsmuster wie MVC und M-V-VM, die Ihre Stärken und Schwächen haben.
Wie auch immer die Architektur im Detail aussieht, man sollte in der Präsentationsschicht die Stärken von WPF (DataBinding, Templates)nutzen und nicht dagegen arbeiten.
Design Resourcen
Die Strukturierung von Design-Resourcen dagegen ist eine Sache, die man sehr gut verallgemeinern kann. Die Struktur, die ich immer wieder erfolgreich für Projekte einsetze, basiert im Großen und Ganzen auf Paul Stovell's
exzellenten XAML and WPF Coding Guidelines.
Ich will hier nicht den Inhalt des Artikels wiedergeben, sondern auf die Dinge eingehen, die ich ein bischen anders mache:
Resource-DLLs: wir packen i.d. Regel alle Resourcen in ein eigenes Projekt/DLL. Das hat den Vorteil, daß der Designer zum Testen ein eigenes, separates Projekt nutzen kann, das wie die eigentliche Anwendung die Resource-DLL einbindet.
StaticResources: es stimmt, daß StaticResources eine Performance Verbesserung bringen. Andererseits wird damit die Reihenfolge, in der Resource Dictionaries eingebunden werden, auf einmal kritisch. Blend kommt damit oft nicht gut klar. Ich rate mittlerweile dazu, erst kurz vor Schluss von DynamicResource auf StaticResource umzustellen.
Namenskonventionen:
- Die PART_ Konvention ist nur für Teile (Parts) von Control Templates gedacht.
- Für andere Namen (nicht zu verwechseln mit Resource-Keys) wählt man besser die selben Bezeichner, die man auch in C# benutzen würde und verwendet das x:Name Attribut zusammen mit x:FieldModifier.
Resource Dictionaries: Was in Flash die Bibliothek ist, sind in WPF und Silverlight die Resource Dictionaries.
Ich halte es für eine gute Idee, Resource Keys zu verwenden, die mit dem Filesystem übereinstimmen.
Z.B. x:Key="Shared/Brushes/Background"
Entsprechend würde ich die Datei dann auch Brushes.xaml statt BrushResources.xaml nennen.
Wie bei der Implementierung selbst auch, ist die Bezeichnung von Resourcen eine sehr wichtige Sache und es zahlt sich aus, dabei sorgfältig vorzugehen.
Ich würde bei der Namen-Wahl immer vom Verwendungszweck ausgehen:
Z.B. statt
x:Key="Brush_TransparentBlue
besser:
x:Key="Shared/Brushes/DialogButtonBackground
Es ist sicher nicht immer einfach, so einen systematischen Aufbau im Team durchzusetzen und aufrecht zu erhalten, aber spätestens in der Wartungsphase oder nach dem Urlaub wird es sich auszahlen.
Viel Spass,
Florian