Microsoft behindert komponentenorientierte Architektur – ein wenig
Update: Danke an Mathias für sein Stichwort WPF User Control Library
Warum ist es im aktuellen Visual Studio 2010 nicht möglich, in einem DLL-Projekt eine WPF Form zu erzeugen? Mint WinForms geht’s, mit WPF nicht. Es scheint so, als fehle Microsoft das Vorstellungsvermögen, dass jemand seine GUI in DLLs auslagert. Genau das ist aber bei komponentenorientierter Architektur praktisch immer der Fall.
Der Vollständigkeit halber noch meine Definition von “komponentenorientierter Architektur”: eine Komponente ist eine binäre Funktionseinheit mit separatem Kontrakt. Binär meint hier, dass eine Komponente nicht im Quelltext verwendet wird, sondern die Referenz auf eine binäre Form, sprich eine Assembly, hergestellt wird. Separater Kontrakt bedeutet, dass die Exportschnittstelle der Komponente in einer separaten Assembly liegt. Somit besteht jede Komponente aus mindestens zwei Assemblies. Eine enthält den Kontrakt, eine weitere die Implementierung. Natürlich wird die Implementierung von Tests begleitet, die wiederum in eigenen Assemblies liegen. In einer komponentenorientierten Architektur ist die Komponente die kleinste Funktionseinheit, um die sich Architekten kümmern. Alles was darunter liegt, insbesondere Klassen, liegt unter dem Radar der Architekten.
Doch zurück zum Tooling. Die komponentenorientierte Architektur hat den Vorteil, dass die Komponenten aus denen eine Anwendung besteht, untereinander klar definierte Beziehungen haben. Denn diese Beziehungen sind von den Architekten während der Planung eines Features definiert worden. Komponentenbeziehungen entstehen also nicht “aus versehen” sondern immer geplant. Nur so ist gewährleistet, dass es im Laufe der Zeit nicht zu undurchschaubaren Abhängigkeiten kommt. Natürlich muss dazu jede Komponenten eine klar abgegrenzte Verantwortlichkeit haben. Und dies bedingt unter anderem, dass die Benutzerschnittstelle nicht mit anderem Zeugs in einen Topf geworfen wird. Folglich muss es für den Entwickler leicht sein, die Benutzerschnittstelle in Form von Komponenten zu implementieren. Mit WinForms war und ist das auch kein Problem. Die Komponenten für die Benutzerschnittstelle sind Library-Projekte wie bei allen anderen Komponenten auch. In Library-Pojekten kann eine WinForms Form mit Visual Studio ganz leicht hinzugefügt werden. Wieso geht das nicht mit WPF?
Für sachdienliche Hinweise bin ich dankbar. Wie lege ich WPF Forms in DLL Projekten an?
Tags: Clean Code Developer
May 20th, 2010 at 12:18
Was genau geht denn bei Dir nicht? Bei mir funktioniert das ohne Probleme. NLocaliize z.B. verwendet eine eigene Klassenbibliothek für das UI.
File > New Project > WPF User Control Library.
May 20th, 2010 at 12:27
Ich schließe mich Matthias an. Ich habe mit der User Control Lib kein Problem.
Es geht natürlich auch “tricky” über Umwege. New -> WPF Application. Dann Properties -> Output Type -> Class Library. Zum Schluss noch die App.xaml entfernen und Build – Geht wunderbar! HTH!
May 20th, 2010 at 12:55
Arg… ich bin einfach zu dämlich…. WPF User Control Library war das richtige Stichwort. Aber wie soll man da als eingefleischter WinForms Entwickler drauf kommen
Danke für den Tipp!
May 20th, 2010 at 13:34
Servus,
und für den Brownfield-Anwendungsfall, sei dieser Tipp genannt: http://www.tom-mue.de/blog/2009/10/kein-designer-in-expression-blend-3-no.html
HTH
TOM_MUE
May 20th, 2010 at 15:09
Stimmt, aus einer reinern Class Library heraus geht es nicht. Das ist leider im Projekt Template irgendwie verhunzt. Wie bereits durch Mathias erwähnt, einfach hier die WPF User Control Library verwenden.
Übrigens, Starker Titel
May 20th, 2010 at 15:23
@Dariusz Habe den Titel ja im Nachhinein schon etwas abgeschwächt
Es bleibt aber dabei, Komponentenorientierung wie ich sie oben skizziert habe ist mit Visual Studio nicht einfach. Ich habe sogar das Gefühl, dass Microsoft eher für das Gegenteil steht: eine Solution mit Hunderten von Projekten. So hängt dann schnell alles mit allem zusammen, weil ja der gesamte Quellcode immer komplett im Zugriff ist. Da kann man den Architekten gleich kündigen
Ich bevorzuge eine Solution pro Komponente. Wenn es schwer ist, sich über die definierten Kontrakte hinwegzusetzen ist das ein Vorteil und kein Problem.