Das Beispielprojekt

Zur Demonstration habe ich ein Beispielprogramm mit MVP entwickelt, welches einen sehr einfachen Twitterclient darstellt. Das Beispiel wurde nach Contract-First komponentenorientiert gebaut und besteht neben der MVP-Komponente aus weiteren Komponenten.

Die weiteren Komponenten haben nichts mit MVP zu tun, sondern sollen nur zeigen, wie man MVP in diesem Umfeld integriert. -> Den kompletten Sourcecode downloaden

Die Funktionen des Twitter-Clients sollen sein:
1. Anzeige der 20 neuesten Meldungen aus der Timeline im Hauptfenster
2. Der Benutzer soll Status-Updates bei Twitter posten können
3. Die Zugangsdaten des Twitter-Accounts sollen gespeichert werden können

Die WinForm-Komponente

Um die Funktionen abzubilden, sind 3 Screens notwendig:
1. Hauptbildschirm mit der Timeline des Twitter-Accounts
2. Form für das Absenden eines Twitter-Status-Updates
3. Konfigurationsbildschirm für den Twitter-Account

Jedes WinForm besteht aus einer View-Klasse (dem WinForm), einem Model, welches als Singleton im IoC-Container konfiguriert wird und einem Presenter. Die einzelnen Funktionen in den Views sind im Beispielprojekt durch Tests abgedeckt und zeigen die notwendigen Tests für diese Art der Implementierung. Gerade durch geringen Funktionsumfang kann man das Muster der Verwendung gut erkennen.

In der MVP-Komponente befindet sich auch der “Inversion of Control”-Container, der die einzelnen Komponenten zusammenfügt. Dies könnte auch in einer extra Runner-Komponente ausgelagert sein.

Aufrufen eines weiteren WinForms

Alle Abhängigkeiten werden per Dependency-Injection-Container an den Presenter übergeben. Da das Hauptform alle weiteren Views und Presenter instanziert, müssten diese alle bereits beim Programmstart instanziert werden. Um dies zu verhindern, habe ich eine IPresenterFactory eingeführt, die zur Laufzeit weitere Presenter nachinstanzieren kann. Die Factory selbst hält eine Referenz auf den Container und wird bei Programmstart im Container hinzugefügt. Um sicherzustellen, dass weiterhin alle anderen Abhängigkeiten über den Konstruktor definiert werden, können aus dieser Factory nur Klassen instanziert werden, die IPresenter implementieren.

Fazit
Mit dieser Beispielanwendung kann man eine mögliche Implementierung von Model View Presenter in der Variante Supervising Controller sehen. Es ist also auch mit WinForms eine voll getestete MVP-Implementierung zu erstellen.

Anhang:
Kompletter Sourcecode der Beispielanwendung als ZIP

Auf der Suche nach einer Lösung zur besseren Testbarkeit stößt man immer wieder auf ein MVC- oder MVP-Modell, aber nirgends gibt es echte Beispiele in Verbindung mit WinForms. Ich möchte nun in einer Demo-Anwendung einen möglichen Ansatz zur Umsetzung des MVP-Patterns bei WinForms beschreiben.

Die einzelnen Bestandteile von MVP

Das Model repräsentiert den gesamten Zustand und die Logik der Ansicht. Das Model wird über den Presenter gefüllt. Die View enthält keinerlei Anwendungslogik, während der Presenter den Programmablauf steuert.

MVP gibt es in zwei Varianten – “Passive View” und “Supervising Controller”. Ich habe mich bei der Implementierung für “Supervising Controller” entschieden, da es auf den ersten Blick weniger Code erfordert. Der Unterschied von beiden Varianten besteht darin, dass bei “Passive View” die View weder Presenter noch Model kennt und als dumme View nur über den Presenter befüllt wird. Mir gefällt dabei jedoch nicht, dass der Presenter dabei die View genau kennen muss.

Bei “Supervising Controller” kennt nun jeweils die View als auch der Presenter das Model, darüber findet der Datenaustausch statt.

Die konkrete Implementierung

Der Presenter wird mit der View und dem Model instanziert.

Die View ist das WinForm und wird auch mit dem Model instanziert. Das Model selbst ist ein über den IoC-Container realisiertes Singleton.

Das Model beinhaltet nur Properties mit allen Daten, die zur Anzeige der View notwendig sind.

Wenn der Presenter Daten im Model ändert, ruft dieser explizit eine UpdateMethode in der View auf. Die View selbst stellt EventHandler zur Verfügung, auf die sich der Presenter hängt, um Aktionen auf der View weiter zu bearbeiten.

Im Presenter sieht dies folgendermaßen aus:

Damit ist die Grundlage des MVP Patterns bei WinForms angelegt. Der Presenter ist damit schon voll testbar, da er komplett von der View abgekoppelt ist. Bis jetzt sieht alles sehr einfach aus. Auch einige andere Beispiele aus dem Netz gehen soweit. Doch wie instanziert man jetzt eine weitere View bzw. einen weiteren Presenter?

Mehr dazu im zweiten Teil

Nehmen wir zum Beispiel ein einfaches Formular. Nach Absenden des Formulars sollen die Werte aus den 2 Feldern addiert werden. Wenn man per QueryString einen Parameter multiple übergibt, soll das Ergebnis damit multipliziert werden.

Und nun zum Quellcode: Die automatisch erstellte .designer.cs muss entfernt werden, was man sowieso tun sollte, da man automatisch erstellten Code – also Code, den keiner außer Microsoft unter Kontrolle hat – vermeiden sollte.
Die Inhalte der .designer.cs – also die Definitionen der Web-Elemente – werden in der Klasse als Public Properties erstellt und instantiiert, um bei Zugriffen wie TextBox.Text keine NullReferenceException zu bekommen.

Um das Verhalten testen zu können, haben wir Adapter für die Klassen System.Web.UI.Page, System.Web.HttpRequest und System.Web.HttpResponse geschrieben, und zwar für die Properties und Methoden die uns vorerst interessieren: z.B. Page.IsPostBack, Page.Request, Response.Redirect(string url, bool endResponse). Bei der Benennung haben wir einfach den Namespace System mit framework.Testable ersetzt und wir haben natürlich zu jedem Testable-Objekt einen Interface erstellt.

Um alle gemockte Objekte setzen zu können, haben wir unserer Page-Klasse auch Setter für Request und Response gegeben. Da man Request.Params nicht setzen kann, d.h. Request.Params[] immer ein NullReferenceException verursachen würde, haben wir das Auslesen der Request-Parameter in eine Methode Request.GetParamValue(string name) ausgelagert.

Das war ungefähr alles: in der Seite nutzt man dann anstelle der eigenen Request und Response-Objekten die Testable-Objekte.

Damit ist die Web-Anwendung bereit zum Testen. So schaut zum Beispiel ein Test für das Laden der Seite aus:

Und so für PostBack inklusive QueryString-Parameter:

Dieses Vorgehen hat uns nicht nur den seit langen gesuchten Weg zum Testen von Webanwendungen geebnet, sondern zwingt auch den Entwickler dazu, alle Funktionalitäten, die nicht in einer Webseite sondern in die dll-s gehören, auszulagern. Damit dürfte es auch der richtige Weg der Clean Code Developers für die Arbeit mit WebForms sein.

Was die Adapter-Klassen betrifft: inzwischen haben wir auch System.IO “adaptiert” und bald werden die anderen System-Klassen folgen, je nach Bedarf.
Download VS2008-Projekt

für “internal”-Elemente gibt es auch die Option mit [assembly:
InternalsVisibleTo("TestAssembly")] zu arbeiten. Alternativ kannst du die zu
testenden Klassen auch per “Add existing item” und dann “Add as link” (siehe
kleines Dreieck neben dem “Add”-Button) zum Testprojekt hinzufügen.

(Danke Alex)

Danach war nur noch ein wenig Surfen nötig, um alles zu erfahren:

msdn sagt:

Vorbereitung

Über Reflection kann man zur Laufzeit relativ einfach an alle Informationen eines Assembly herankommen. So ist es möglich, dass man von einem Assembly den Namen, Klassen, Methoden mit ihren Parametern, Eigenschaften und Rückgabewerte, usw. auslesen kann. Aber nicht nur das Auslesen ist möglich, sondern auch das Setzen.

Jetzt stellt sich für den einen oder anderen vielleicht die Frage, warum man zur Laufzeit auf diese Daten zugreifen kann. Jede Assembly verfügt über Module in denen sich die einzelnen Typen(Klassen) befinden. Für jedes Modul gibt es Metadaten, in denen die einzelnen Typen beschrieben werden. Die Assembly selbst verfügt noch über ein Manifest, in dem sich alle Informationen zum Assembly (z.B. Name, Version) befinden. Wenn man über Reflection auf Assemblies zugreift, dann werden diese Metadaten und das Manifest dafür herangezogen. Die Metadaten verfügen zwar noch über die Informationen, welche Modifizierer für Methoden, Properties, usw. verwendet wurden, aber der MSIL-Code (die Zwischensprache, die vom Endcompiler in die plattformspezifische Sprache übersetzt wird) nicht mehr. Die Modifizierer sind nur für den Compiler relevant und werden nach dem Kompilieren nicht mehr berücksichtigt. Somit ist es auch möglich über Reflection Properties, Methoden, usw. zu verwenden, die nicht öffentlich sind.

Für dieses Beispiel habe ich eine kleine Konsolen-Anwendung geschrieben (TestApplication), welche eine Referenz auf das Assembly TestProject.dll hat. Dieses Assembly hat zwei von mir erstellte Typen (Klassen) TestClass und SecondTestClass. In den beiden Klassen steckt keine Logik. Sie sind ausschließlich für dieses Beispiel erstellt worden, um ein paar Daten zu modifizieren und um zu zeigen wie die Informationen aus dem Assembly ausgelesen und verändert werden können und dass es möglich ist an nicht-öffentliche Methoden heranzukommen.

TestClass.cs

using System.Security.Cryptography;

using System.Text;

namespace TestProject {

class TestClass {

    public string Name { get; set; }

    public string Surname { get; set; }

    private string Password { get; set; }

    public string GetFullName() {

        return string.Format("{0} {1}", Name ?? string.Empty, Surname ?? string.Empty).Trim();

    }

    public void SetPasswort(string password){

        Password = password;

    }

    private static string CalcPassword(string password){

        MD5 md5 = MD5.Create();

        byte[] data = md5.ComputeHash(Encoding.Default.GetBytes(password));

        StringBuilder hashPassword = new StringBuilder();

        foreach (byte b in data){

            hashPassword.Append(b);

        }

        return hashPassword.ToString();

    }

    public static string DoSomething(string value) {

        // do something

        return value;

    }

}

SecondTestClass.cs

namespace TestProject {

    public class SecondTestClass {

        public int Addition(int a, int b) {

            return a + b;

        }

        public int Multiply(int a, int b) {

            return a * b;

        }

        public double Divide(int a, int b) {

            if (b == 0) return 0;

            return a / b;

        }

    }

}
.
.

Auslesen von Assembly- Type-Informationen

Mit der Methode Thread.GetDomain().GetAssemblies() bekommt man alle referenzierten Assemblies der aktuellen Domäne. Damit die TestProject-Assembly auch in dieser Domäne vorhanden ist, muss vor dem Aufruf dieser Methode eine Instanz von einem Objekt dieses Assemblies erzeugt werden.

Um sich nun alle Assemblies der aktuellen Domäne anzeigen zu lassen, könnte man folgendes schreiben:

static void Main(string[] args) {

    SecondTestClass secondTestClass = new SecondTest Class();

    Assembly[] assemblies = Thread.GetDomain().GetAssemblies();

    foreach (var assembly in assemblies) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name
                                                          , assembly.GetName().Version));

    }

    Console.ReadLine();

}

.

Nun könnte man noch alle zur Verfügung stehenden Typen(Klassen) aus der TestProject-Assembly anzeigen.

static void Main(string[] args) {

    SecondTestClass secondTestClass = new SecondTestClass();

    Assembly[] assemblies = Thread.GetDomain().GetAssemblies();

    foreach (var assembly in assemblies) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name
                                                          , assembly.GetName().Version));

        if (assembly.GetName().Name.Equals("TestProject")) {

            Type[] types = assembly.GetTypes();

            foreach (var type in types) {

                Console.WriteLine("  ++{0}", type.Name);

            }

        }

    }

    Console.ReadLine();

}

.

Wenn man nun allerdings Informationen eines bestimmten Types haben möchte, so werden diese Informationen aus den Metadaten des Moduls geladen, in dem sich der Type befindet. Um zum Beispiel alle öffentlichen Methoden eines Types anzuzeigen, könnte man folgendes schreiben:

static void Main(string[] args) {

    SecondTestClass secondTestClass = new SecondTestClass();

    Assembly[] assemblies = Thread.GetDomain().GetAssemblies();

    foreach (var assembly in assemblies) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name
                                                          , assembly.GetName().Version));

        if (assembly.GetName().Name.Equals("TestProject")) {

            Type[] types = assembly.GetTypes();

            foreach (var type in types) {

                Console.WriteLine("  ++ {0}", type.Name);

                MethodInfo[] methodInfos = type.GetMethods();

                foreach (var info in methodInfos) {

                    Console.WriteLine("    ++ {0}", info.Name);

                }

            }

        }

    }

    Console.ReadLine();

}

.

Es fällt auf, dass auch die Methoden ToString, Equals, GetHashCode und GetType in beiden Klassen angezeigt werden, obwohl diese in den Klassen überhaupt nicht deklariert wurden. Das liegt daran, dass alle Typen von object ableiten und object diese Methoden implementiert. Was noch auffällt ist, dass nur öffentliche Methoden angezeigt werden. Möchte man sich auch die privaten Methoden anzeigen lassen, so muss man der Methode type.GetMethods Parameter übergeben. Diese Methode verlangt BindingFlags, die man mit dem Bitweise ODER-Operator (|) miteinander verknüpfen kann. Um sich nun öffentliche und private Methoden anzeigen zu lassen, muss der Aufruf der Methode type.GetMethods folgendermaßen lauten:

MethodInfo[] methodInfos = type.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);

Dieser Aufruf gibt an, dass man alle öffentlichen und nicht-öffentlichen Instanz-Methoden bekommen möchte. Instanz-Methoden bedeutet, dass es sich um Methoden handelt, die nur mit dem Instanzieren eines Objektes zur Verfügung stehen. D.h. es werden keine static-Methoden angezeigt. Es gibt noch weitere BindingFlags, auf die ich hier allerdings nicht weiter eingehen möchte.

Das ganze könnte man natürlich noch in der Form weiter treiben, dass man sich die kompletten Methodensignaturen mit Modifizierer, Schlüsselwort und Rückgabewert anzeigen lässt:

static void Main(string[] args) {

    SecondTestClass secondTestClass = new SecondTestClass();

    Assembly[] assemblies = Thread.GetDomain().GetAssemblies();

    foreach (var assembly in assemblies) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name, assembly.GetName().Version));

        if (assembly.GetName().Name.Equals("TestProject")) {

            Type[] types = assembly.GetTypes();

            foreach (var type in types) {

                Console.WriteLine("  ++ {0}", type.Name);

                MethodInfo[] methodInfos = type.GetMethods(BindingFlags.Public | BindingFlags.NonPublic
                                                                               | BindingFlags.Instance
                                                                               | BindingFlags.Static);

                foreach (var info in methodInfos) {

                    string modifier = GetModifier(info);

                    string keyword = GetKeyword(info);

                    string parameters = GetParameters(info);

                    if (!string.IsNullOrEmpty(keyword)) {

                        keyword = string.Format("{0} ", keyword);

                    }

                    Console.WriteLine("    ++ {0} {1}{2}{3}({4})", modifier, keyword
                                                                 , info.ReturnParameter, info.Name, parameters);

                }

            }

        }

    }

    Console.ReadLine();

}

private static string GetModifier(MethodInfo info) {

    if (info.IsPublic) return "public";

    return "private";

}

private static string GetKeyword(MethodInfo info) {

    if (info.IsStatic) return "static";

    if (info.IsVirtual) return "virtual";

    return string.Empty;

}

private static string GetParameters(MethodInfo info) {

    StringBuilder parameters = new StringBuilder();

    ParameterInfo[] parameterInfos = info.GetParameters();

    if (parameterInfos != null) {

        foreach (ParameterInfo parameterInfo in parameterInfos) {

            if (!string.IsNullOrEmpty(parameters.ToString())) {

                parameters.Append(", ");

            }

            parameters.AppendFormat("{0} {1}", parameterInfo.ParameterType.Name, parameterInfo.Name);

        }

    }

    return parameters.ToString();

}

.

Nicht immer ist bereits während der Entwicklung bekannt, aus welchem Assembly man Informationen benötigt. Sodass die Methode Thread.GetDomain().GetAssemblies() nicht verwendet werden kann. Eine weitere Möglichkeit an ein Assembly zu kommen ist es direkt zu laden. Dafür bietet die Klasse Assembly die statische Methode Assembly.LoadFrom zum Laden von Assemblies. Statt dem Laden des Assembly über die aktuelle Domäne, wird das nächste Beispiel so modifiziert, dass die TestProject-Assembly direkt aus einem Verzeichnis heraus geladen wird.

static void Main(string[] args) {

    Assembly assembly = Assembly.LoadFrom(@"c:\TestProject.dll");

    if (assembly != null) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name, assembly.GetName().Version));

        Type[] types = assembly.GetTypes();

        foreach (var type in types) {

            Console.WriteLine("  ++ {0}", type.Name);

            MethodInfo[] methodInfos =

            type.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance |

            BindingFlags.Static);

            foreach (var info in methodInfos) {

                string modifier = GetModifier(info);

                string keyword = GetKeyword(info);

                string parameters = GetParameters(info);

                if (!string.IsNullOrEmpty(keyword)) {

                    keyword = string.Format("{0} ", keyword);

                }

                Console.WriteLine("    ++ {0} {1}{2}{3}({4})", modifier, keyword, info.ReturnParameter,

                info.Name, parameters);

            }

        }

    }

    Console.ReadLine();

}

Man sieht, dass die gleiche Ausgabe wie bereits im vorherigen Beispiel generiert wird.

.

Interaktionen

Nachdem die Vorgehensweise nun klar sein sollte, möchte ich nun den eigentlich interessanten Teil demonstrieren. Wie kann man nun auf Methoden usw. zugreifen und wie können Werte aus einem Type gelesen und veränder werden? Wenn man die Methode SecondTestClass.Addition(int a, int b) aufrufen möchte, dann braucht man die Methodeninformationen von dem Type SecondTestClass aus dem TestProject-Assembly. D.h. man muss wie in den obigen Beispielen auch über alle Typen iterieren, um an den gesuchten Type SecondTestClass zu kommen. Hat man den gesuchten Type gefunden, so kann man sich von diesem alle Methoden in einem Array zurückgeben lassen. Dieses Array kann dann wieder ganz normal durchlaufen und nach der gewünschten Methode durchsucht werden. Hat man die Methode gefunden so muss zuerst eine Instanz von dem Objekt erzeugt werden und dafür gibt es den Activator, der die statische Methode CreateInstance beinhaltet. Als Parameter übergibt man ihr den Type von dem eine Instanz erzeugt werden soll. Jetzt kann man über die MethodInfo die Methode aufrufen. Dazu muss der Methode die Instanz des Objektes übergeben werden, von welchem die Methode aufgerufen werden soll und zusätzlich noch ein Array von Objekten, welche die zu übergebenen Parameter beinhaltet. Hat die Methode keine Parameter, so muss null übergeben werden. Dabei muss der Rückgabewert in den erwarteten Wert gecastet werden. Das ganze könnte dann folgendermaßen aussehen:

static void Main(string[] args) {

    Assembly assembly = Assembly.LoadFrom(@"c:\TestProject.dll");

    if (assembly != null) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name, assembly.GetName().Version));

        Type[] types = assembly.GetTypes();

        foreach (var type in types) {

            if (type.Name.Equals("SecondTestClass")) {

                Console.WriteLine("  ++ {0}", type.Name);

                MethodInfo[] methodInfos = type.GetMethods();

                foreach (var info in methodInfos) {

                    if (info.Name.Equals("Addition")) {

                        object obj = Activator.CreateInstance(type);

                        int value = (int)info.Invoke(obj, new object[] { 2, 5 });

                        Console.WriteLine("    ++ {0}(2 + 5) = {1}", info.Name, value);

                    }

                }

            }

        }

    }

    Console.ReadLine();

}

Aufruf der Methode Addition

.

Bei statischen Methoden kann das Erzeugen der Instanz weggelassen werden und für den Parameter des Instanz-Objektes kann null übergeben werden.

if (type.Name.Equals("TestClass")) {

    Console.WriteLine("  ++ {0}", type.Name);

    MethodInfo[] methodInfos = type.GetMethods(BindingFlags.NonPublic | BindingFlags.Static);

    foreach (var info in methodInfos) {

        if (info.Name.Equals("CalcPassword")) {

            string value = (string)info.Invoke(null, new object[] { "myPassword" });

            Console.WriteLine("    ++ {0}(\"myPassword\") = {1}", info.Name, value);

        }

    }

}

Das übergebene Passwort wurde über eine statische Methode gehashed.

.

Um den Wert einer Property auszulesen, muss anstelle von MethodInfo die PropertyInfo verwendet werden. Aus dieser kann dann über die Methode PropertyInfo.GetValue der aktuelle Wert zurückgegeben werden. Da in diesem Beispiel nach dem Instanzieren des Objektes noch keine Werte zugewiesen wurden, sind die Properties leer.

static void Main(string[] args) {

    Assembly assembly = Assembly.LoadFrom(@"C:\ TestProject.dll");

    if (assembly != null) {

        Console.WriteLine(string.Format("-- {0} ver.: {1}", assembly.GetName().Name, assembly.GetName().Version));

        Type[] types = assembly.GetTypes();

        foreach (var type in types) {

            if (type.Name.Equals("TestClass")) {

                Console.WriteLine("  ++ {0}", type.Name);
                object obj = Activator.CreateInstance(type);

                PropertyInfo[] propertyInfos = type.GetProperties(BindingFlags.Public | BindingFlags.NonPublic
                                                                                      | BindingFlags.Instance);

                foreach (var info in propertyInfos) {

                    Console.WriteLine("    ++ {0} = {1}", info.Name, info.GetValue(obj, null));

                }

            }

        }

    }

    Console.ReadLine();

}

.

Wenn man nun die Properties mit Werten belegen möchte, so muss man analog zur Methode PropertyInfo.GetValue, die Methode PropertyInfo. SetValue verwenden.

if (type.Name.Equals("TestClass")) {

    Console.WriteLine("  ++ {0}", type.Name);

    PropertyInfo[] propertyInfos = type.GetProperties(BindingFlags.Public | BindingFlags.NonPublic
                                                                          | BindingFlags.Instance);

    propertyInfos[0].SetValue(obj, "Peter", null);

    propertyInfos[1].SetValue(obj, "Müller", null);

    propertyInfos[2].SetValue(obj, "myPassword", null);

    foreach (var info in propertyInfos) {

        Console.WriteLine("    ++ {0} = {1}", info.Name, info.GetValue(obj, null));

    }

}

.

.

Wozu braucht man jetzt aber nun die Reflection?

Nun ja, die meisten Programme werden Reflection wohl nie benötigen oder verwenden. Es wird vorallem bei dem Entwickeln von Debuggern, Interpretern, TestTools, Logger oder auch für O/R-Mapper verwendet. Es wird also überall dort gebraucht, wo während der Laufzeit nicht klar ist, welche Assemblies verwendet werden und welche Informationen man aus diesen lesen oder manipulieren möchte.

.

kurze Zusammenfassung:

Wie man gesehen hat, ist der Aufbau einer Assembly mit ihren Typen hierarchisch. Um zb. an einen Parameter einer Methode eines Types zu kommen, braucht man zuerst das Assembly welches den Typ enthält. Von diesem lässt man sich ein Array von Typen geben. Von dem gesuchten Typ lässt man sich dann ein Array von Methoden geben. Von der gesuchten Methode holt man sich nun ein Array von allen Parametern. Dieses Array kann dann nach dem gewünschten Parameter durchsucht werden.

Es gibt natürlich für all diese Methoden auch Methoden, mit denen man sich den Type, die Methodeninformation, die Parameterinformation, usw. direkt mit der entsprechenden Bezeichnung holen kann. Ich wollte hier nur auf die Hierarchie aufmerksam machen.

Wie man in diesen Beispielen erkennen konnte, ist es möglich, ohne Probleme auf alle Informationen von einem Assembly zuzgreifen, sich die Types zu laden, dessen öffentliche und auch nicht-öffentliche Werte zu lesen und zu manipulieren und auch Methoden auszuführen. Man kann sich auch lokale Werte anzeigen lassen, in dem man sich den MethodBody des Objekte geben lässt, von denen man die lokalen Werte ermitteln möchte.

Definiert und intstanziert werden sie mit new und einem Objektinitialisierer:

    var mitarbeiter = new { Name = "Müller", Abteilung = "IT" };

var ist der implizite Typ und nicht der anonyme Datentyp. Er fungiert hier lediglich als container für die Instanz des anonymen Datentyps, die mit new {} erzeugt wird.

Gibt man keinen Namen für die Properties an, werden die Namen der Properties verwendet, mit denen initialisiert wird.

    var abteilung = new { Abteilungsname = "IT" };

    var mitarbeiter = new { Name = "Müller", abteilung.Abteilungsname };

    Console.WriteLine(mitarbeiter.Abteilungsname);

Wenn man mit Werten initialisiert, muss ein Name angegeben werden.

Anonyme Datentypen bieten sich an, wenn man Abfragen mit Linq ausführt und entweder nur eine Teilmenge des ursprünglichen Objekts braucht, oder wenn man ein Objekt erweitern will, ohne extra eine neue Klasse zu definieren.

Hier ein Beispiel aus einem Castle Monorail Projekt, in dem eine erweiterte Liste an eine vm gegeben wird, ohne eine neue Klasse definieren zu müssen. Es soll dabei eine Liste erstellt werden, in der die Mitarbeiter mit ihrem Horoskop verknüpft werden :

    public void Action() {

        IList<Mitarbeiter> mitarbeiterListe = m_service.GetMitarbeiter();

        var mitarbeiterMitHoroskopListe = (from mitarbeiter in mitarbeiterListe

            select new { Mitarbeiter = mitarbeiter,

                         Horoskop = GetHoroskop(mitarbeiter.Geburtsdatum) });

        PropertyBag["mitarbeiterMitHoroskopListe"] = mitarbeiterMitHoroskopListe;

    }

Vor einiger Zeit stand ich vor dem Problem, dass ich zur Laufzeit Assemblies austauschen wollte. Grund dafür war, dass ich eine Host-Applikation hatte, die Plug-Ins verwendet. Jetzt wollte ich bestehende Plug-Ins während der Laufzeit austauschen oder neue Plug-Ins hinzufügen ohne die Host-Applikation zu beenden. Dazu hatte ich ein Verzeichnis in dem sich, außer den Plug-Ins, alle Assemblies befanden. Die Plug-Ins selbst befanden sich in einem eigenen Unterverzeichnis. Selbst wenn die Plug-Ins von der Host-Applikation nicht mehr verwendet wurden, war es nicht möglich, diese Assemblies zu löschen.

Im Normalfall ist es so, dass sobald eine Assembly von einer Applikation verwendet wird, eine Referenz auf diese existiert. Diese Referenz wird leider erst gelöscht, wenn die ganze Applikation beendet wird.

Bei dem dynamischen Laden von Assemblies wird die zu ladende Assembly geöffnet, ausgelesen und dann geschlossen. Aus den ausgelesenen Bytes wird dann mittels Reflection eine Assembly im Arbeitsspeicher erzeugt. Auf die lokale Assembly hängt somit keine Referenz und es ist möglich diese zu löschen.

Meine Umsetzung sieht folgendermaßen aus:

    2 public IList<Plugin> GetPlugins(string assemblyName) {

    3     Assembly assembly;

    4     IList<Plugin> pluginList = new IList<Plugin>();

    5     try {

    6         byte[] byteAssembly = File.ReadAllBytes(assemblyName);

    7         assembly = Assembly.Load(byteAssembly);

    8     } catch (Exception ex) {

    9         log.Error(ex);

   10     }

   11     try {

   12         if (assembly != null) {

   13             Type[] assemblyTypes = assembly.GetTypes();

   14             foreach (Type assemblyTyp in assemblyTypes) {

   15                 if (typeof(Plugin).IsAssignableFrom(assemblyTyp)) {

   16                     plugin = (Plugin)assembly.CreateInstance(assemblyTyp

   17                                                                 .FullName);

   18                     if (plugin != null) {

   19                         pluginList.Add(plugin);

   20                     }

   21                 }

   22             }

   23         }

   24     } catch (ReflectionTypeLoadException ex) {

   25         log.Error(ex);

   26     }

   27     return pluginList;

   28 }

• eine Host-Applikation die das Plug-In laden möchte
• ein Plug-In welches es zu laden gilt
• und die Schnittstellen Plugin und IHost

Zu allererst brauchen wir eine gemeinsame Schnittstelle, die sowohl vom Plug-In als auch vom Host (die Applikation welche das Plug-In verwenden soll) benutzt werden soll. Über diese Schnittstelle kommuniziert der Host mit dem Plug-In.
Es würde sich das Interface IPlugIn anbieten. In meinem Fall verwende ich allerdings kein Interface sondern eine abstrakte Klasse, da ich bereits Logik direkt in die Schnittstelle implementieren möchte. In meinem Fall heißt die abstrakte Klasse einfach nur Plugin. Im weiteren Verlauf werde ich zu meiner abstrakten Klasse Schnittstelle sagen.

    1 public abstract class Plugin {

    2     private IHost m_host;

    3     public Plugin(string name) {

    4         Name = name;

    5     }

    6

    7     public string Name { get; set; }

    8     public string Author { get; set; }

    9     public string Version { get; set; }

   10     public bool IsRegistered { get; private set; }

   11

   12     /// <summary>

   13     /// Setzt oder gibt die Host-Application.

   14     /// </summary>

   15     /// <value>Host-Application.</value>

   16     public IHost Host {

   17         get { return m_host; }

   18         set {

   19             if (value != null) {

   20                 if (m_host == null) {

   21                     m_host = value;

   22                     if (m_host.Register(this)) {

   23                         IsRegistered = true;

   24                     }

   25                 }

   26             } else {

   27                 if (m_host.Unregister(this)) {

   28                     m_host = value;

   29                     IsRegistered = false;

   30                 }

   31             }

   32         }

   33     }

   34 }

Ich glaube, der Aufbau der Schnittstelle Plugin sollte bis auf die Property “Host” klar sein. Wie man sieht, benötigt man bei diesem Pattern zusätzlich zur Schnittstelle Plugin noch das IHost-Interface.
Dieses Interface ist direkter Bestandteil der Schnittstelle Plugin. Nun kann man sich natürlich die Frage stellen, warum das Plug-In den Host kennen muss und somit von diesem abhängig ist.

Zum einen ist es in der Regel so, dass ein Plug-In für nur einen Host entwickelt wird und zum anderen wollte ich dem Host gewisse Richtlinien zum Registrieren und Lösen des Plug-Ins vorgeben.

Das Interface IHost sieht folgendermaßen aus:

    1 public interface IHost {

    2     bool Register(Plugin plugin);

    3     bool Unregister(Plugin plugin);

    4 }

Dieses Interface muss von der Host-Applikation implementiert werden, damit sich das Plug-In am Host registrieren kann. Im letzten Satz habe ich es schon angedeutet. Nicht der Host registriert das Plug-In bei sich, sondern das Plug-In registriert sich am Host. Durch das setzen der Property Plugin.Host wird die Methode Register oder Unregister vom Plug-In aufgerufen, welche der Host implementiert.

Eine vereinfachte Darstellung der Implementierung des IHost -Interfaces sieht folgendermaßen aus:

    1 public class HostApplication : IHost {

    2     private List<Plugin> m_pluginList;

    3

    4     //Konstruktor

    5     public HostApplication() {

    6         m_pluginList = new List<Plugin>();

    7

    8         //Lädt alle verfügbaren Plug-Ins zb. aus einem Verzeichnis

    9         List<Plugin> plugins = GetPlugins();

   10         foreach (Plugin plugin in plugins) {

   11             //ruft implizit die IHost.Register-Methode auf

   12             plugin.Host = this;

   13         }

   14     }

   15

   16     public void ShowPlugins() {

   17         foreach (Plugin plugin in m_pluginList) {

   18             //Ausgabe der Namen aller am Host registrierten Plug-Ins

   19             Console.WriteLine(plugin.Name);

   20         }

   21     }

   22

   23     public void UnloadPlugins() {

   24         foreach (Plugin plugin in m_pluginList) {

   25             //ruft implizit die IHost.Unregister-Methode auf

   26             plugin.Host = null;

   27         }

   28     }

   29

   30     #region IHost-Implementierung

   31     public bool Register(Plugin plugin) {

   32         if (!m_pluginList.Contains(plugin)) {

   33             m_pluginList.Add(plugin);

   34             return true;

   35         }

   36         return false;

   37     }

   38

   39     public bool Unregister(Plugin plugin) {

   40         if (m_pluginList.Contains(plugin)) {

   41             m_pluginList.Remove(plugin);

   42             return true;

   43         }

   44         return false;

   45     }

   46     #endregion

   47 }

Das Registrieren und Lösen der Plug-Ins könnte man nun noch in einen Plug-In-Manager auslagern, worauf ich in diesem Blog allerdings verzichten möchte.