Author Archive

Nach dem ich meinen vorherigen Artikel zum Thema “Asynchrone Kommunikation mit dem Async-Pattern” vorgestellt hatte, hat Ralf Westphal auf seinem Blog “One Man Think Tank Gedanken” das Vorgehen zur Implementierung einer asynchronen Kommunikation mit Hilfe von Event-Based-Components vorgestellt, welches eine sehr gute Alternative zum Async-Pattern ist. Seinen Eintrag nehme ich zum Anlass, um meine Beispiel-Implementierung des Async-Pattern zu refaktorisieren, um eine bessere Trennung der Verantwortlichkeiten und somit eine bessere Lesbarkeit zu erreichen.

In das Form wird die Abhängigkeit “CalcProxy” injected.

static void Main()

{

    CalcProxy calcProxy = new CalcProxy(new Calculator());

    Application.EnableVisualStyles();

    Application.SetCompatibleTextRenderingDefault(false);

    Application.Run(new Form1(calcProxy));

}

 

Im Gegensatz zur vorherigen Version wird in der Form nun nicht mehr der Calculator direkt erzeugt und verwendet, sondern auf den injekteten CalcProxy zugegriffen.

public partial class Form1 : Form {

    private readonly ICalcProxy m_calcProxy;

    public Form1(ICalcProxy calcProxy) {

        InitializeComponent();

        m_calcProxy = calcProxy;

        m_calcProxy.CalcCompleted += CalculatorCalcCompleted;

    }

 

    private void Run_Click(object sender, EventArgs e) {

        int number;

        if (Int32.TryParse(txbEingabe.Text, out number)) {

            m_calcProxy.CalcAsync(number, number);

        }

    }

 

    void CalculatorCalcCompleted(object sender, CalcEventArgs eventArgs) {

        lblCounter.Text = eventArgs.UserState.ToString();

    }

}

 

Der CalcProxy wiederum bekommt die Abhängigkeit zum Calculator injected und stellt für die Calculator.Calc-Methode sowohl eine synchrone als auch eine asynchrone Methode zur Verfügung.

public class CalcProxy : ICalcProxy {

    private readonly ICalculator m_calculator;

    public event CalcCompletedEventHandler CalcCompleted;

    private AsyncOperation m_asyncOperation;

    private bool m_isRunning;

 

    public CalcProxy(ICalculator calculator) {

        m_calculator = calculator;

    }

 

    public int Calc(int number) {

        return m_calculator.Calc(number);

    }

 

    public void CalcAsync(int number, object userState) {

        lock (this) {

            if (m_isRunning) {

                throw new InvalidOperationException("Diese Operation wird bereits ausgeführt");

            }

            m_isRunning = true;

            m_asyncOperation = AsyncOperationManager.CreateOperation(userState);

            ThreadPool.QueueUserWorkItem(ExecuteCalc, number);

        }

    }

 

    private void ExecuteCalc(object state) {

        var result = Calc((int)state);

        m_asyncOperation.PostOperationCompleted(CalcCompletedSuccessful, result);

    }

 

    private void CalcCompletedSuccessful(object result) {

        if (CalcCompleted != null) {

            CalcCompleted(this, new CalcEventArgs(null, false, (int)result, result));

        }

    }

}

 

Nun enthält der Calculator nur noch die Methode die für den Calculator notwendig ist, nämlich die Calc-Methode.

public class Calculator : ICalculator {

    public int Calc(int number) {

        Thread.Sleep(10000);

        return number * number;

    }

}

kick it on dotnet-kicks.de

Comments 4 Comments »

Bevor ich anhand eines Beispiels zeige, wie man mit Hilfe des Async-Pattern ein asynchrone Kommunikation implementieren kann, möchte ich kurz beschreiben, wo der Unterschied zwischen der synchronen und der asynchronen Kommunikation liegt und wofür die asynchrone Kommunikation nützlich ist.

Synchrone Kommunikation

Bei der synchronen Kommunikation handelt es sich um eine Echtzeit-Kommunikation. Das bedeutet, dass Anfragen und Antworten jeweils vollständig nacheinander abgearbeitet werden. Kommuniziert ein Prozess mit einem Webserver synchron, so ist der Prozess solange blockiert, bis er die vollständige Antwort vom Webserver erhalten hat.

Asynchrone Kommunikation

Im Gegensatz zur synchronen Kommunikation handelt es sich bei der asynchronen Kommunikation nicht um eine Echtzeit-Kommunikation. Das bedeutet, dass bei der Kommunikation eines Prozesses mit einem Webserver der Prozess nicht blockiert. Der Prozess verschickt lediglich die Anfrage an den Webserver und kehrt danach sofort zur weiteren Prozessausführung zurück. Der Prozess geht dabei davon aus, dass die Anfrage an den Webservice korrekt gestellt wurde. Die Antwort wird dann zu einem unbestimmten Zeitpunkt vom Webservice geliefert, und zwar dann, wenn dieser mit der Abarbeitung der Anfrage fertig ist.

Warum Asynchrone Kommunikation

Asynchrone Kommunikation bietet sich in unterschiedlichsten Situationen an. So ist es z.B. sinnvoll, dass eine WinForms-Anwendung asynchron mit einem Webservice kommuniziert, da der Haupt-Thread der WinForm-Anwendung sonst so lange blockiert wäre, bis der Webservice die Antwort auf die Anfrage liefert. Die Folge wäre, dass im Titel der Anwendung stehen würde, dass die Anwendung nicht antwortet (s. Abbildung 1). Viele Benutzer denken dass es sich bei dieser Meldung um einen Fehler im Programm handelt und beenden das Programm fix über den Task-Manager. Dabei lag es nur an der etwas länger dauernden Kommunikation zwischen der WinForm-Anwendung und dem Webservice.

Abbildung 1

Ein weiterer Grund für eine asynchrone Kommunikation wäre, wenn eine Anwendung nur Nachrichten verschicken möchte und es im Grunde keine Rolle spielt, ob diese Nachricht korrekt verarbeitet wurde. Vorstellbar wäre hier Loggen von Aktionen. Mir wäre es jetzt egal, ob die Nachricht korrekt gespeichert wurde oder nicht. Ich will nur nicht, dass meine Anwendung, nur weil Daten geloggt werden müssen, langsamer wird. Es handelt sich ja bei den Log-Daten nicht um Informationen die für die Abarbeitung notwendig sind.

Ein weiterer Fall wäre z. B. das Skalieren von Datenbankabfragen. So könnten mehrere Threads gleichzeitig Daten von gleichen oder unterschiedlichen Datenbeständen abfragen um schnellere Antwortzeiten zu erhalten.

Beispiel

Um die asynchrone Kommunikation zu realisieren gibt es unterschiedliche Möglichkeiten. Ich habe mich allerdings für eine Event-Based-Variante entschieden. Der große Vorteil von einem Event-Based Async-Pattern liegt in meinen Augen darin, dass der Nutzer von asynchrone Methoden sich nicht wirklich mit Multithread-Umgebungen auskennen muss. Für den Nutzer ist es völlig transparent wie die Threads im Hintergrund erzeugt werden und wie die Synchronisation der einzelnen Thread funktioniert. Für den Nutzer ist es nur wichtig zu wissen, dass er eine Methode aufrufen kann die asynchron abläuft und somit nicht den erwarteten Rückgabewert besitzt wie die synchrone Methode und dass ein Event ausgelöst wird, wenn die Methode komplett abgearbeitet wurde und der erwartete Rückgabewert zur Verfügung steht.

Nun aber genug geredet, jetzt wird programmiert. Für das Beispiel habe ich mich für eine WinForm-Anwendung entschieden, die nichts anderes tut, als die eingegebene Zahl zu quadrieren. Diese Berechnung dauert aufgrund eines Thread.Sleep() zehn Sekunden, um eine verzögerte Ausführung zu simulieren. Die Berechnung habe ich dabei in eine extra Komponente ausgelagert, die eine Schnittstelle zur asynchronen Kommunikation bereitstellt. Dabei gilt es eine gewisse Namenskonvention einzuhalten. Neben der synchronen Methode „Calc“, wird die asynchrone Methode mit dem Zusatz „Async“ bezeichnet („CalcAsync“). Da das Async-Pattern Event-Based ist, muss ein Event bereitgestellt werden, welches ausgelöst wird, wenn die asynchrone Verarbeitung beendet wurde. Laut Namenskonvention muss solch ein Event „<Methodenname>Completed“ heißen. Mein Event heißt somit „CalcCompleted“.

Die Abbildung 2 zeigt die UI der Anwendung. Bei dem Drücken des „Run“-Buttons, soll die eingegebene Zahl asynchron quadriert werden und im Anschluss in das Feld „Ergebnis“ ausgegeben werden.

Abbildung 2

Der Code hinter der UI sieht folgendermaßen aus. Beim instanziieren des Forms, wird eine Instanz des Calculators erstellt und ein Delegate auf das „CalcCompleted“-Event registriert. Dieses Event wird aufgerufen sobald der Calculator mit der Berechnung fertig ist.

Bei dem Drücken des „Run“-Buttons, wird die Methode Calculator.CalcAsync(…) aufgerufen.

public partial class Form1 : Form {

        private ICalculator m_calculator;

        public Form1() {

            InitializeComponent();

            m_calculator = new Calculator();

            m_calculator.CalcCompleted += Calculator_CalcCompleted;

        }

 

        private void Run_Click(object sender, EventArgs e) {

            int number;

            if (Int32.TryParse(txbEingabe.Text, out number)) {

                m_calculator.CalcAsync(number, number);

            }

        }

 

        void Calculator_CalcCompleted(object sender, CalcEventArgs eventArgs) {

            lblCounter.Text = eventArgs.Result.ToString();

        }

    }

Sobald die Berechnung fertig ist, wird das CalcCompleted-Event ausgelöst und somit die Calculator_CalcComplete-Methode aufgerufen und das Ergebnis der Berechnung in ein Label geschrieben. Der große Vorteil ist, dass man sich an dieser Stelle nicht mehr um die Synchronisierung der Threads kümmern muss, sodass man direkt auf das Label schreiben darf und es nicht zu einem threadübergreifenden Zugriff kommt.

Der Calculator sieht wie folgt aus:

       

public interface ICalculator {

        event Calculator.CalcCompletedEventHandler CalcCompleted;

        int Calc(int number);

        void CalcAsync(int number, object userState);

    }

 

    public class Calculator : ICalculator {

        public delegate void CalcCompletedEventHandler(object sender, CalcEventArgs eventArgs);

        public event CalcCompletedEventHandler CalcCompleted;

        private AsyncOperation m_asyncOperation;

        private bool m_isRunning;

 

        public int Calc(int number) {

            Thread.Sleep(10000);

            return number * number;

        }

 

        public void CalcAsync(int number, object userState) {

            lock (this) {

                if (m_isRunning) {

                    throw new InvalidOperationException("Diese Operation wird bereits ausgeführt");

                }

                m_isRunning = true;

                m_asyncOperation = AsyncOperationManager.CreateOperation(userState);

                ThreadPool.QueueUserWorkItem(ExecuteCalc, number);

            }

        }

        .

        .

        .

    }

Wie man im Interface des Calculator sieht, gibt es eine synchrone und eine asynchrone Methode für die Berechnung. Uns interessiert allerdings nur die asynchrone Methode. Das lock und die Prüfung auf m_isRunning verhindern lediglich, dass die asynchrone Methode während ihrer Ausführung öfter aufgerufen wird. Das Wesentliche an dieser Methode ist der Aufruf von AsyncOperationManager.CreateOperation, denn dieser Aufruf stellt einen Synchronisationskontext bereit, der die Threads miteinander synchronisiert. Für die eigentliche Berechnung wird sich über den ThreadPool ein neuer Thread besorgt, der sich dann um die Abarbeitung der ExecuteCalc in einem eigenen Thread kümmert.

public class Calculator : ICalculator {

        .

        .

        .

        private void ExecuteCalc(object state) {

            int result = Calc((int)state);

            m_asyncOperation.PostOperationCompleted(CalcCompletedSuccessful, result);

        }

 

        private void CalcCompletedSuccessful(object result) {

            if (CalcCompleted != null) {

                CalcCompleted(this, new CalcEventArgs(null, false, (int)result, result));

            }

        }

    }

    public class CalcEventArgs : AsyncCompletedEventArgs {

        public CalcEventArgs(Exception error, bool cancelled, int result, object userState)

            : base(error, cancelled, userState) {

            Result = result;

        }

        public int Result { get; private set; }

    }

Sobald die Berechnung abgeschlossen ist, wird der Thread mit dem MainThread über den Aufruf von PostOperationCompleted synchronisiert und das CalcCompleted-Event ausgelöst und das Ergebnis in das Label geschrieben (s. o.).

6 public partial class Form1 : Form {

7 private ICalculator m_calculator;

8 public Form1() {

9 InitializeComponent();

10 m_calculator = new Calculator();

11 m_calculator.CalcCompleted += Calculator_CalcCompleted;

12 }

13

14 private void Run_Click(object sender, EventArgs e) {

15 int number;

16 if (Int32.TryParse(txbEingabe.Text, out number)) {

17 m_calculator.CalcAsync(number, number);

18 }

19 }

20

21 void Calculator_CalcCompleted(object sender, CalcEventArgs eventArgs) {

22 lblCounter.Text = eventArgs.UserState.ToString();

23 }

24 }

kick it on dotnet-kicks.de

Comments 3 Comments »

prio_2009_468x60_statisch_01

In den vergangenen Tagen fand im Marriott Hotel München die prio.conference 2009 statt. Thema dieser Konferenz war in diesem Jahr „User Interface“. Dies war meine erste prio und ich muss sagen ich bin echt begeistert. Leider waren (für mich) einige interessante Sessions parallel, sodass ich mich oft nicht entscheiden konnte, welche Session ich besuchen soll. Toll ist natürlich auch, dass sich bei solchen Veranstaltungen immer die Möglichkeiten ergeben, sich mit anderen Entwicklern zu unterhalten und zu erfahren, wie sie gewisse Dinge beurteilen, planen und umsetzen.

Meine besuchten Sessions:

– Mein neuer PC ist ein Handy

– Auflösungsunabhängige Darstellung von Benutzeroberflächen

– Passive View Command Pattern – Agile User Interfaces Entwicklung mit TDD

– Responsive UI’s Grundlagen

– Responsive UI’s mit der Task Parallel Library

– Auf dem Weg zu guten User Interfaces

– Usability-Testing – ganz einfach

– The IPhone as an Application Plattform for .Net Developer

– Herangehensweise für das Redesign einer Software

– Von der Idee zur fertigen UI – für Entwickler

– Mustergültig – GUI Design-Patterns

– UI – das fremde Wesen

Ich für meinen Teil kann sagen, dass ich viel von dieser Veranstaltung mitgenommen habe.

Vielen Dank

Comments 2 Comments »

Ü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 »

Heute habe ich einen recht interessanten Artikel gelesen. In diesem ging es darum besseren Code zu schreiben, zu warten und im allgemeinen besser mit ihm umzugehen. Die Rede ist dabei von Clean-Code-Developer.

Dabei geht es weder darum neue Technologien zu verwenden, noch darum neue Sprachen zu erlernen. Eigentlich ist es eher ein kleiner Leitfaden um sich stetig zu verbessern, und das wollen wir doch im Allgemeinen eh, sonst würde dieser Blog-Eintrag wohl auch nicht gelesen.

Comments 2 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 »