Think First Development

Schon einmal einen Programmierer sagen hören “Diese neue Technologie ist cool. Die sollten wir einsetzen”. Hört man auf den Programmierer und setzt die Technologie einfach ein? Wie ist das denn wenn der Kunde sagt “Diese neue Technologie ist cool. Die solltet ihr einsetzen”. Sollte man die Technologie jetzt einsetzen? Neue Technologien bieten auch neue Chancen für das Produkt und neue Motivation für Entwickler.

Der erste Schritt liegt auf der Hand. Mittels eines Proof Of Concept wird die neue Technologie getestet und verifiziert, ob die Technologie zur Architektur passt. Aber wie geht es weiter? Die folgenden fünf Fragen geben eine Entscheidungshilfe für die Entscheidung.

• Erfüllt die Technologie die Anforderungen an die Architektur?
• Will der Kunde diese Technologie haben?
• Wollen die Entwickler diese Technologie einsetzen?
• Wie groß ist der Einfluss der Technologie auf den bestehenden Code?
• Wie leicht lässt sich diese Technologie bei einer Fehlauswahl wieder entfernen?

Zu guter letzt muss wieder der Architekt entscheiden, aber doch bitte bewusst und nach objektiven Kriterien und nicht nach Bauchgefühl.

Nachdem ich mich die letzte Woche mit PostSharp beschäftigt habe schreibe ich hier nun mein Ergebnis: AOP mit PostSharp ist einfach genial. So einfach möchte ich es auch nicht machen, also etwas mehr Informationen.

PostSharp ist ein Framework zum Implementieren von Aspekt Orientierter Programmierung (AOP). Das Ziel ist eine nachträgliche und separate Implementierung von Aspekten in eine Applikation. Klassische Beispiele hierfür sind Logging und Security. PostSharp ist so implementiert, dass die Aspekte mittels Attribut an Methoden, Eigenschaften usw. gehangen werden. Der Post-Compiler von PostSharp ändert nach dem Kompilieren durch Visual Studio die Assembly. PostSharp kann hier heruntergeladen werden. Zum Abschluss noch ein interessanter Hinweis. PostSharp kopiert die Assemblies in das Ausgabeverzeichnis die auf dem Client benötigt werden. PostSharp muss auf den Client nicht installiert werden.

Funktionsweise von PostSharp (Bild: PostSharp)

Das folgende Beispiel zeigt eine DoSomething Methode, welche über einen Logging-Aspect nachträglich geloggt wird. Der Code der LoggingAspect Klasse zeigt die Implementierung der Aspects über das PostSharp Framework. Dem Projekt müssen die Referenzen auf die Assemblies “PostSharp.Laos” und “PostSharp.Public” hinzugefügt werden.

    public class Program
    {
        public static int Main(string[] args)
        {
            DoSomething();

            Console.Read();
            return 0;
        }

        [LogAcpect()]
        private static void DoSomething()
        {
            Console.WriteLine("Hello World");
        }
    }

    [Serializable()]
    public class LogAcpect : OnMethodBoundaryAspect
    {
        public override void OnEntry(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Calling: {0} ---", eventArgs.Method);
        }

        public override void OnExit(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Leaving: {0} ---", eventArgs.Method);
        }

        public override void OnSuccess(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Success: {0} ---", eventArgs.Method);
        }

        public override void OnException(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Exception: {0} @ {1} ---", eventArgs.Exception.Message, eventArgs.Method);
        }
    }

An dieser Stelle noch einen paar Hinweise. Die Klasse LogAspect muss als Serializable deklariert werden, ansonsten gibt es beim Starten einen Fehler. Weiterhin ist die Klasse LogAspect eine Attribut-Klasse und kann wie eine solche mit Eigenschaften und überladenen Konstruktoren implementiert werden. Der folgende Code zeigt eine disassemblierte Version der Funktion. Hier sieht man genau, welche Methoden an welcher Stelle aufgerufen werden und das man mittels FlowBehaviour eine Methode kontrolliert abbrechen kann und das eine Exception in der Aspect-Klasse nach “oben” durchgereicht wird.

private static void DoSomething()
{
    MethodExecutionEventArgs ~laosEventArgs~1;
    try
    {
        ~laosEventArgs~1 = new MethodExecutionEventArgs(~PostSharp~Laos~Implementation.~targetMethod~1, null, null);
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnEntry(~laosEventArgs~1);
        if (~laosEventArgs~1.FlowBehavior != FlowBehavior.Return)
        {
            Console.WriteLine("Hello World");
            ~PostSharp~Laos~Implementation.LogAcpect~1.OnSuccess(~laosEventArgs~1);
        }
    }
    catch (Exception ~exception~0)
    {
        ~laosEventArgs~1.Exception = ~exception~0;
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnException(~laosEventArgs~1);
        switch (~laosEventArgs~1.FlowBehavior)
        {
            case FlowBehavior.Continue:
            case FlowBehavior.Return:
                return;
        }
        throw;
    }
    finally
    {
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnExit(~laosEventArgs~1);
    }
}

Die Implementierung eines Security-Aspect hängt von den Bedürfnissen der Applikation ab. In meinem aktuellen Projekt haben wir in einer Datenbank einem Benutzer eine oder mehrere Funktionen zugewiesen. Der SecurityAspect prüft gegen eine IFunctionProvider-Schnittstelle, ob dem Benutzer die entsprechenden Funktion zugeordnet wurde. Die Funktion wird über den Konstruktor der SecurityAspect-Attibutes angegeben. Besteht der Anwender die Sicherheitsabfrage nicht, wird eine SecurityException geworfen. Diese Exception kann mittels Try-Catch abgefangen werden. Eine solche Implementierung stellt sicher, dass Methoden nur dann ausgeführt werden, wenn die Sicherheitsrichtlinien erfüllt werden. Die GUI stellt selbstverständlich a priori sicher, dass eine solche Methode nicht aufgerufen werden kann, wenn der Anwender keine hinreichenden Berechtigungen besitzt.

        [SecurityAcpect(FunctionEnumeration.DoSomething)]
        private static void DoSomething()
        {
            Console.WriteLine("Hello World");
        }

Die aspektorientierte Programmierung ist nur ein Aspekt des Postsharp Frameworks. Die Stärke des Frameworks liegt in der, wie auch immer gearteten, nachträglichen Modifizierung des Codes.