Archive for the “How-To” Category

Im Teil 1 (MVP mit WinForms) habe ich die Grundgedanken zur Implementierung von MVP in WinForms vorgestellt, mit der man WinForm-Anwendungen mit UnitTests abdecken kann. In einer komplexeren WinForm-Anwendung gibt es neben dem Startform auch mehrere Unterforms, die durch das Hauptform aufgerufen werden müssen.

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

kick it on dotnet-kicks.de

Comments 3 Comments »

Wir setzen seit langer Zeit interne Tools mit WinForms um und hatten seit Anfang an Probleme bei der Testbarkeit dieser Anwendungen. Auch wenn man bei WinForms versucht, jeglichen Code aus der Codebehind-Datei zu entfernen, tut man sich mit dem Unit-Testing weiterhin schwer.

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.

10 public class MainPresenter : IMainPresenter

11 {

12 private readonly IMainView m_view;

13 private readonly IMainModel m_model;

14

15 public MainPresenter(IMainView view, IMainModel model)

16 {

17 m_view = view;

18 m_model = model;

19

20 InitializeModelAndRefreshView();

21 InitializeAndShowView();

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

10 public partial class MainView : Form, IMainView

11 {

12 private readonly IMainModel m_model;

13

14 public MainView(IMainModel model)

15 {

16 m_model = model;

17

18 InitializeComponent();

19 this.Closed += delegate { ViewClosed(this, new EventArgs()); };

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.

60 public event EventHandler<EventArgs> ViewClosed;

Im Presenter sieht dies folgendermaßen aus:

31 private void InitializeAndShowView()

32 {

33 m_view.Title = “ResourcerClient V1.0”;

34 m_view.ViewClosed += new EventHandler<EventArgs>(mainView_ViewClosed);

42 void mainView_ViewClosed(object sender, EventArgs e)

43 {

44 Application.Exit();

45 }

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

kick it on dotnet-kicks.de

Comments 5 Comments »

Obwohl die allgemeine Meinung ist, dass es sehr schwierig sei, kann man mit folgendem Workaround Webforms sehr einfach und sehr umfangreich testen. Bedingung 1: als Projekt kein Web Site Project sondern eine Web Application erstellen. Bedingung 2: Business Logic in die entsprechende Schicht auslagern.

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.

Testable WebForm   Testable WebForm Sent

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.

    1 using System;

    2 using System.Web.UI.HtmlControls;

    3 using System.Web.UI.WebControls;

    4 using framework.Testable.Web.UI;

    5 

    6 namespace TestableWebForm

    7 {

    8     public class DefaultPage : System.Web.UI.Page

    9     {

   10 

   11         #region Controls

   12         public HtmlForm Formular;

   13         public TextBox Value1 = new TextBox();

   14         public TextBox Value2 = new TextBox();

   15         public Label Result = new Label();

   16         public Button Submit = new Button();

   17         #endregion

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.

    1 

    2 namespace framework.Testable.Web

    3 {

    4     namespace UI

    5     {

    6         public interface IPage

    7         {

    8             bool IsPostBack{ get; }

    9             IHttpRequest Request{ get; set; }

   10             IHttpResponse Response{ get; set; }

   11         }

   12 

   13         public class Page : IPage

   14         {

   15             private readonly System.Web.UI.Page m_page;

   16             private IHttpRequest m_request;

   17             private IHttpResponse m_response;

   18 

   19             public Page( System.Web.UI.Page page )

   20             {

   21                 m_page = page;

   22                 m_request = new HttpRequest( m_page );

   23                 m_response = new HttpResponse( m_page );

   24             }

   25 

   26             public bool IsPostBack

   27             {

   28                 get{ return m_page.IsPostBack; }

   29             }

   30 

   31             public IHttpRequest Request

   32             {

   33                 get{ return m_request; }

   34                 set { m_request = value; }

   35             }

   36 

   37             public IHttpResponse Response

   38             {

   39                 get{ return m_response; }

   40                 set { m_response = value; }

   41             }

   42         }

   43     }

   44 }

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.

    8     public class DefaultPage : System.Web.UI.Page

    9     {

   …

   19         private IPage m_page;

   20         public void SetTestableObjects( IPage page )

   21         {

   22             m_page = page;

   23         }

   24 

   25         public void Page_Load( object sender, EventArgs e )

   26         {

   27             if (m_page == null) m_page = new Page( this );

   28             int multiple = 1;

   29             if (!string.IsNullOrEmpty( m_page.Request.GetParamValue( "multiple" ) )) multiple = Convert.ToInt32( m_page.Request.GetParamValue( "multiple" ) );

   30             if (m_page.IsPostBack)

   31             {

   32                 Result.Text = ( (Convert.ToInt32( Value1.Text ) + Convert.ToInt32( Value2.Text ))*multiple ).ToString();

   33             }

   34         }

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

    1 using framework.Testable.Web;

    2 using framework.Testable.Web.UI;

    3 using NUnit.Framework;

    4 using Rhino.Mocks;

    5 using TestableWebForm;

    6 

    7 namespace Tests

    8 {

    9     [TestFixture]

   10     public class WebFormTests

   11     {

   12         private IPage m_page;

   13         private IHttpRequest m_request;

   14         private IHttpResponse m_response;

   15         private DefaultPage m_defaultPage;

   16 

   17         [SetUp]

   18         public void Init()

   19         {

   20             m_page = MockRepository.GenerateStub<IPage>();

   21             m_request = MockRepository.GenerateStub<IHttpRequest>();

   22             m_response = MockRepository.GenerateStub<IHttpResponse>();

   23             m_page.Request = m_request;

   24             m_page.Response = m_response;

   25         }

   26 

   27         [Test]

   28         public void PageLoad_Loading_EmptyFields()

   29         {

   30             // Arrange

   31 

   32 

   33             // Act

   34             m_defaultPage = new DefaultPage();

   35             m_defaultPage.SetTestableObjects(m_page);

   36             m_defaultPage.Page_Load( null, null );

   37 

   38             // Assert

   39             Assert.IsEmpty( m_defaultPage.Value1.Text );

   40             Assert.IsEmpty( m_defaultPage.Value2.Text );

   41             Assert.IsEmpty(m_defaultPage.Result.Text);

   42         }

Und so für PostBack inklusive QueryString-Parameter:

   63         [Test]

   64         public void PageLoad_PostBackWithRequestValue_ResultIsCorrect()

   65         {

   66             // Arrange

   67             const int value1 = 1;

   68             const int value2 = 2;

   69             const int value3 = 3;

   70             m_request.Expect( a => a.GetParamValue( "multiple" ) ).IgnoreArguments().Repeat.Twice().Return( value3.ToString() );

   71             m_page.Expect( a => a.IsPostBack ).Return( true );

   72 

   73             // Act

   74             m_defaultPage = new DefaultPage();

   75             m_defaultPage.SetTestableObjects( m_page );

   76             m_defaultPage.Value1.Text = value1.ToString();

   77             m_defaultPage.Value2.Text = value2.ToString();

   78             m_defaultPage.Page_Load( null, null );

   79 

   80             // Assert

   81             Assert.IsTrue( m_defaultPage.Result.Text == ( (value1 + value2)*value3 ).ToString() );

   82         }

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

kick it on dotnet-kicks.de

Comments No Comments »

Wir fragen uns seit langem, wie man internal Methoden testen kann, da eins klar ist, die Kapselung darf nicht wegen der Testfähigkeit verletzt werden.
Letzte Woche hatte zum Glück auch jemand anderer dieses Problem und er hat gleich bei CCD-GoogleGroup nachgefragt. Und so haben wir auch erfahren, wie die Lösung lautet:

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:

InternalsVisibleToAttribute Class

Specifies that types that are ordinarily visible only within the current assembly are visible to another assembly.

User comment:
It is not documented anywhere to my knowledge, but if you want to grant “InternalsVisibleTo” permission to more than one assembly, you need to understand the syntax.

To do this you should NOT insert multiples instances of:

[assembly: InternalsVisibleTo("FirstAssembly")]

Instead do this:

[assembly: InternalsVisibleTo("FirstAssembly"),
InternalsVisibleTo("SecondAssembly"),
InternalsVisibleTo("ThirdAssembly")]

The former syntax is legal but fails, because each instance simply redefines and replaces any earlier ones, the latter syntax works as required.

kick it on dotnet-kicks.de

Comments 1 Comment »

Ü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. weiter lesen…

Comments No Comments »

Anonyme Datentypen sind Klassen, die erst beim Kompilieren durch den Compiler definiert werden. Die Klassendefinition befindet sich also nicht im Quellcode. Die anonymen Datentypen leiten wie jedes andere Referenzobjekt von der Klasse object ab. Sie sind als reine Datenklassen gedacht und es können keine weiteren Methoden oder Events hinzugefügt werden. Obwohl der anonyme Datentyp auf Quellcodeebene noch nicht definiert ist, muss dank Visual Studio nicht auf die Intellisense verzichtet werden.

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;
    }

Comments No Comments »

In diesem Blog-Post möchte ich kurz erläutern, wie ich mit dem Problem des dynamischen Ladens von Assemblies umgegangen bin.

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 }

Comments No Comments »

In meinem ersten Blog-Post möchte ich euch in vereinfachter Form meine Umsetzung des Plug-In-Patterns vorstellen.
Voraussetzungen für dieses Pattern sind:

  • 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.

Comments No Comments »