Ein paar Unity 2.0 Beispiele

Ich komme kaum noch zum Bloggen, es findet sich immer etwas Wichtigeres. Zu dem fehlt momentan die Kick-Technologie zum bloggen.

Heute stelle ich zumindest mal meine Samples zu Unity 2.0 zum Download. Ich setze in fast all meinen Projekten Unity ein (außer ich muss etwas anderes nutzen), da es sehr simpel und effektiv ist. Unity ist bei Microsoft in eine wichtige Rolle geschlüpft. Heute habe ich gelernt, dass Unity im Exchange Server 2010 verwendet wird. Ich muss mir das zukünftig mal genauer anschauen. Das

Unity kann man Inline konfigurieren, oder per externer Konfiguration initiieren. Bei der Konfiguration per Code werden die Typen und Mappings direkt zum Container hinzugefügt. Die Inline Konfiguration nutze ich als Fallback, falls keine Konfiguration im Container vorhanden ist.

   1:  IUnityContainer container = new UnityContainer();

   2:  container.RegisterType<ITestInterface, TEstRunner>();

   3:  container.RegisterType<ITestInterface, TEstRunner>("specialVersion");

   4:  container.RegisterType<ITestInterface, TEstRunner>("singelton", new ContainerControlledLifetimeManager());

Prüfung, ob eine Definition vorhanden ist.

if(!container.IsRegistered<ITestInterface>())container.RegisterType<ITestInterface, TEstRunner>();

Zur Konfiguration mittels der Konfigurationsdatei muss der Container mit

new UnityContainer().LoadConfiguration();

initialisiert werden. Die Konfiguration könnte zum Beispiel so aussehen:

   1:  <configuration>

   2:    <configSections>

   3:      <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>

   4:    </configSections>

   5:   

   6:    <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

   7:      <alias alias="runner" type="PoC.Unity.Configuration.TEstRunner, PoC.Unity.Configuration"/>

   8:      <alias alias="Iservice" type="PoC.Unity.Configuration.ITestInterface, PoC.Unity.Configuration"/>

   9:      <container>

  10:        <register type="Iservice"  mapTo="runner"/>

  11:        <register type="Iservice"  mapTo="runner" name="specialVersion">

  12:          <lifetime type="perthread"/>

  13:        </register>

  14:        <register type="Iservice"  mapTo="runner" name="singelton">

  15:          <lifetime type="singleton"/>

  16:        </register>

  17:      </container>

  18:    </unity>

  19:  </configuration>

Beim Erstellen eines Objektes durch den Container, können notwendige Abhängigkeiten ohne weitere Aktionen übergeben werden, sofern diese dem Container bekannt sind. (Injection) Ich nutze meistens Konstruktur Injection, da dies aus meiner Sicht die richtige Anwendung für erforderliche Komponenten ist.

   1:  public class TEstRunner : ITestInterface

   2:  {

   3:      private readonly IUnityContainer _container;

   4:      public TEstRunner(IUnityContainer container)

   5:      {

   6:          _container = container;

   7:          Console.WriteLine("Do I have a container? - " + (ReferenceEquals(_container, null) ? "no" : "yes"));

   8:      }

   9:  ...

  10:  }

  11:  container.Resolve<ITestInterface>().Run();

AOP ist etwas komplizierter, sobald es einmal läuft, auch wieder ganz einfach. ;) Allerdings muss man einige Utility-Klassen erstellen, so ist eine Attribute-Klasse und eine Implementierung des ICallHandler-Interface notwendig. Hier zumindest mal die Unity-Konfiguration:

   1:  IUnityContainer uc = new UnityContainer();

   2:  uc.AddNewExtension<Interception>();

   3:  uc.RegisterType<ITestInterface, TEstRunner>();

   4:  uc.Configure<Interception>()

   5:      .SetDefaultInterceptorFor<ITestInterface>(new InterfaceInterceptor());

Eigentlich ist es egal welchen DI/IoC Container man nutzt, es hilft den Code testbarer zu machen und reduziert Abhängigkeiten deutlich. Das Beste Bespiel für die Reduzierung von Abhängigkeiten erlebt man, wenn man mit Prism arbeitet.

Hier noch der Link zu einem schönen Video zu Unity (etwas veraltet): Unity Features and Futures at the patterns and practices Summit 2009

Samples: poc.unity.zip

X-Mas–The art of unit testing

Dieses Jahr habe ich mich mit “The art of unit testing” beschenkt. Wenn ich es gelesen habe, dann steige ich bestimmt zum Sennmeister für Unit testing auf.

Dieses Jahr wurde in einem Projekt endlich Unit testing als sehr wichtiges Instrument genutzt. Allerdings haben wir das klassische Unit testing mit umfangreichen Intregrationstest verbunden. Allerdings mussten wir vorher in den Projekten lernen, was passiert, wenn die Tools nicht testbar sind und immer komplexer werden. Gerade bei der Architektur und dem Design muss auf eine gute Testbarkeit und Entkopplung wert gelegt werden. Derzeit ist für mich das Mittel der Wahl für IoC – Unity, obwohl mich ein Kollege immer von Spring überzeugen will. Bisher kann ich mich bei Spring nur für den AOP-Teil begeistern.

Wer unit tests für Grenzwerte oder mehrere Parameter schreibt, der sollte auch mal einen Blick auf Nunit Attributes schauen. Es gibt viele Möglichkeiten die Tests zu Parametrisieren und so ein bisschen auch FIT oder ähnliche Tools nachzuahmen.

Es gibt noch einiges zu tun in diesem Jahr, ich muss mich noch ganz schön ranhalten. Andererseits muss ich erst mal wieder richtig fit werden. Mein Körper holt sich in den letzten Wochen den fehlenden Urlaub. Obwohl ich mich nicht schlecht fühle, bin ich erst mal krankgeschrieben und muss mich entspannen.