Stefan Liesers Blog

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?

Ich habe das Vergnügen, am 28. Mai auf der diesjährigen dotnet-cologne hier in Köln einen Vortrag zu Brownfield Projekten zu halten. Wer mich kennt weiß, dass ich nicht für Marketingvorträge zur Verfügung stehe. Wenn ein Produkt gut ist, sage ich es. Und wenn es nix taugt, sage ich das  auch Der Vortrag dreht sich zwar um ein konkretes Produkt, nämlich den TypeMock Isolator, aber in der Hauptsache wird es darum gehen, wie man Brownfield Projekte saniert. Darüber schreibe ich auch gerade mit Ralf Westphal bei Heise Developer eine Artikelserie, die ersten drei Artikel sind bereits online.

Der Schwerpunkt des Vortrags liegt auf der Einführung von automatisierten Tests in Brownfield Projekten. Diese Projekte zeichnen sich dadurch aus, dass praktisch keine Architektur vorhanden ist, von automatisierten Tests ganz zu schweigen. In einem solchen undurchschaubaren Klumpen automatisierte Tests einzuführen, ist eine große Herausforderung. Ohne leistungsfähige Testwerkzeuge wie den Isolator ist da praktisch nichts zu machen. Denken Sie allein an Code in Formularen: wenn der zu testende Code gespickt ist mit MessageBox.Show Aufrufen oder Dialoge wie der FileOpenDialog verwendet werden, ist automatisiertes Testen schwierig.

Im Vortrag zeige ich an einigen kleinen Demos, wie man mit TypeMock Isolator Tests in Brownfield Projekten ergänzen kann. Diese sind die Basis für Refaktorisierungen.

Wer einen der begehrten Plätze zur dotnet-cologne ergattern konnte ist eingeladen, meinen Vortrag zu hören. Da ich mit dem Mittagessen konkurrieren muss (Lunch Session), bin ich gespannt wieviele Zuhörer sich einfinden werden…