Roberto's Blog : IoC, LightCore

DI / IoC Container LightCore Teil 3: Registrierung von Generics

Roberto — Sun, 21 Feb 2010 17:18:00 GMT

Im dritten Teil der Post Serie wird die bisher angewandte drei Schichten Struktur etwas erweitert, sodass diese durch das hinzufügen von generischen Klassen etwas mehr flexibel wird.

1. LightCore – Einführung
2. LightCore – Registrierung über Xml Module
3. LightCore – Registrierung von Generics

Generics sind nichts anderes als Klassen, bei denen der Nutzer die Datentypen, die der Typ verarbeiten soll, vorgeben kann.

Es kann durchaus Sinn machen, bei Projekten die Repositories generisch zu halten, da sich diese immer auf dieselbe Datenquelle beziehen(bspw. bei Verwendung des NHibernate OR-Mappers) und sie sich lediglich von den angeforderten Typen unterscheiden.

LightCore bietet zwei Möglichkeiten, generische Typen zu registrieren.

Closed Types

Eine generische Klasse, die schon einen Typparameter hat.
IRepository<User> zu Repository<User> registrieren.

Die Registrierung und Auflösung sieht in dem Fall so aus:

builder.Register<IRepository<User>, Repository<User>();
container.Resolve<IRepository<User>>();

Der Nachteil dieser Variante liegt darin, dass jedes Repository getrennt registriert werden muss (eines für den User, eines für die UserGroup…). Dies wär in dem Fall suboptimal, da sie von den Funktionen her identisch sind.

Open Types

Eine generische Klasse, die keinen bestimmten Parameter hat.
Der Kontrakt, in dem Fall IRepository<> hätte die Implementation Repository<>.

Der Vorteil dabei ist die Auflösung (on-the-fly) auf einem beliebigen Typparameter.
So wäre IRepository<User> und IRepository<UserGroup>.

In dem Fall muss das Repository nur ein einziges Mal registrieren werden und kann mit beliebigem Typ auflöst werden.

Wenn das Projekt ein generisches Repository mit viele verschiedene Typen dazu hat, ist der open type die erste Wahl.

Als Beispiel wird wieder eine Solution mit einer klassischen drei Schichten Architektur verwendet.

Um das Ganze noch etwas zu vertiefen wird eine vierte Schicht „Core“ hinzugefügt. Diese beinhaltet die zentralen Interfaces wie bspw. IRepository oder IService.

Das Repository muss wie oben beschrieben nur einmal registriert werden:

container.Register(typeof(IRepository<>), typeof(Repository<>));

Jetzt könnten alle gewünschten Typen (Im Beispiel user und usergroup) instanziiert werden:

container.resolve<IRepository<User>>();
container.resolve<IRepository<UserGroup>>();

Fazit:

Durch die Unterstützung von generischen Klassen ist Lightcore für mich interessant gewordern und ist bereits in einer Anwendung im Einsatz. Es funktioniert bis dato Problemfrei und ohne merkbare Performance Verluste. Es bietet genau das, was ich zur Zeit benötige. Somit bin ich gespannt auf dessen zukünftige Erweiterungen.

Anbei wie immer das Beispiel nicht vergessen! :-)

LightCore Demo: Einführung
LightCore Demo: Registerirung über Xml Module
LightCore Demo: Registrierung von Generics

DI / IoC Container LightCore Teil 2: Registrierung über Xml Modul

Roberto — Sun, 21 Feb 2010 16:02:00 GMT

Wie bereits im ersten Teil erwähnt, wird es einer mehr Schichten Architektur immer wichtiger, Abhängigkeiten zu minimieren. Dabei einen ersten Schritt zu setzen, ist die Implementierung eines IoC Containers. Dieser hilft dabei, den Code in den diversen Projekten unabhängiger zu halten.

1. LightCore – Einführung
2. LightCore – Registrierung über Xml Module
3. LightCore – Registrierung von Generics

Mich persönlich hat Peter Bucher mit seinem neusten Projekt LightCore darauf aufmerksam gemacht. Anfangs war dies nur als Unit Testing Spielwiese gedacht, hat sich aber zu einem konkurrenzfähigen Micro Kernel entwickelt. Dessen weitere Entwicklung wird in Zukunft per Community gesteuert. Der Source Code wurde veröffentlicht und ist auf jeden Fall einen Blick Wert! (Stichwort: Codequalität)

Zurück zum Thema. Viele werden sich denken, was bringt mir das Ganze eigentlich?

Abhängigkeiten verringern und Kontrolle der Abhängigkeiten (Interface / Basisklasse - also Abstraktion) und dadurch auf die Instanziierung (Die sonst auf den konkreten Typen geht), rausziehen.
Dadurch bessere Testbarkeit und Aufbrechung der Anwendung in mehr Einzelteile, wodurch die Komplexität sinkt.
Außerdem globale Konfigurierbarkeit, was genutzt werden soll um Änderungen an vielen, unnötigen Stellen vorzunehmen.

Nun wird anhand eines Beispiels wird gezeigt, wie man Lightcore in einer drei Schichten Architektur einsetzen bzw. integrieren kann.
Gleichzeitig wird die Registrierung über das integrierte Xml Modul erklärt

Was eine drei Schichten Architektur (Tier 3 layer) ist, erklärt Robert Mühsig in seinem Post.

Das folgende Beispiel wird eine Solution mit mehreren Projekten beinhalten, die eine Anwendung mit mehreren Schichten darstellt.

Die Klassische Struktur sieht wie folgt aus:

Data Access Layer
Business Layer
Presentation Layer

Folglich könnten die Projekte so benannt werden:

Data: beinhaltet eine User Klasse sowie das dazugehörige Repository.

Service: beinhaltet einen User Service mit dem Repository als Member, der per Constructor Injection injiziert wird.

Web: Die Präsentation

Im ersten Teil des Posts wurde gezeigt, wie man Kontrakte einfach per code (global.asax) registrieren kann. Der erste Schritt wird sein, die Registrierung in die Web/App.config bzw. einer eigenen Konfigurationsdatei auszulagern.

Wer achte gibt sieht, dass beim heruntergeladenen Paket unter Anderem eine XML Schema Datei (LightCore.xsd), sowie eine Beispiel Konfiguration (SampleConfiguration.xml) dabei ist.
Nun die Datei LightCore.xsd dem aktuellen Web Projekt hinzufügen.

Es kann eine eigene Konfigurationsdatei erstellt werden, oder aber einfach den entsprechenden Block in die Web/App.config hinzufügen.
Wer sich für letzteres entscheidet, den Block, der innerhalb der SampleConfiguration.xml zu finden ist, einfach in den <configuration> Abschnitt packen.

<configuration>
    …
    <LightCoreConfiguration xmlns="clr-namespace:LightCore.Configuration;assembly=LightCore.Configuration">

Als erstes kommt die Einstellung über den genutzten Lebenszyklus, also ob Singleton, Transient oder HttpRequest.

<LightCoreConfiguration.TypeAliases>
    <TypeAlias Alias="HttpRequest" Type="LightCore.Integration.Web.HttpRequestLifecycle, LightCore.Integration.Web"/>
</LightCoreConfiguration.TypeAliases>

Jetzt die eigentliche Registrierung.
Einfache Registrierungen ohne Gruppen kommen in die LightCoreConfiguration.Registrations Sektion:

<LightCoreConfiguration.Registrations>
    <Registration Name="MyRepository" ContractType="MyAssembly.IUserRepository, MyAssembly" ImplementationType="MyAssembly.Repository, MyAssembly" />
</LightCoreConfiguration.Registrations>

Sollte selbsterklärend sein, Namensangabe um den registrierten Kontrakt wiederzufinden, der Kontrakttyp sowie die Klasse mit jeweiliger Angabe des Assembly Namens. Optionale Argumente für den Konstruktor können über Arguments=“Value1, Value2“ mitgegeben werden. Wenn die LightCore.xsd im Projekt eingebunden wurde, sollte auch IntelliSense zur Verfügung stehen!

Ist eine gruppierte Registrierung gewollt, um bspw. die Repositories zu sammeln, gibt es auch hierfür eine Sektion:

<LightCoreConfiguration.RegistrationGroups>
    <RegistrationGroup Name="Repositories">
        <RegistrationGroup.Registrations>
            <Registration Name="MyRepository" ContractType="MyAssembly.IUserRepository, MyAssembly" ImplementationType="MyAssembly.Repository, MyAssembly" />
        </RegistrationGroup.Registrations>
    </RegistrationGroup>
</LightCoreConfiguration.RegistrationGroups>

Jetzt wo die Registrierung der Repositories gemacht wurde, muss der Container erstellt und das Konfigurationsmodul zugewiesen werden.

Dies sollte in der Globalen Anwendungsdatei (global.asax) in der Application_Start methode gemacht werden:

protected void Application_Start(object sender, EventArgs e)
{
    var builder = new ContainerBuilder();
    var module = new XamlRegistrationModule();
    builder.RegisterModule(module);
    _container = builder.Build();
}

Wenn gewollt, kann die Konfigurationsdatei im Konstruktor des XamlRegistrationModules angegeben werden:

var module = new XamlRegistrationModule("~/MyConfiguration.xml")

Die Objekte können wie gehabt mit resolve aufgelöst werden

var myRepository = _container.Resolve<IRepository>("MyRepository");

Fazit: Welche Variante ist nun besser?

Registrierung per Code hat den Vorteil, dass weniger Fehler auftreten können.
Da es kompiliert werden muss, wird überprüft ob der Kontrakt implementiert ist oder nicht.

Somit ist es intuitiver und Refactoring-sicher. Wenn eine Klasse umbenannt wird – wird sie auch hier übernommen.

Allerdings hat die Registrierung per Code einen riesen Haken: Es ist eine harte – also feste – Referenz.
Wenn eine Assembly, aus welchem Grund auch immer, ausgetauscht wird, muss das komplette Projekt neu kompiliert werden.

Sollte das bei einer Produktivumgebung der Fall sein, kann das ein großer Nachteil sein. Dadurch muss ein komplettes Deployment gemacht werden.

Was also „besser“ ist, hängt vom Anwendungsfall ab.
Ich persönlich finde die „per Code“ Variante bei nicht allzu vielen Klassen übersichtlich.
Eine gut durchdachte Anwendungsstruktur von Anfang an ist natürlich Voraussetzung :-)

Anbei gibt’s wie immer das oben gezeigte Beispiel als Download.

LightCore Demo: Einführung
LightCore Demo: Registerirung über Xml Module
LightCore Demo: Registrierung von Generics

DI / IoC Container LightCore Teil 1: Einführung

Roberto — Sat, 16 Jan 2010 16:03:00 GMT

In einer mehrschichtigen Architektur (Oft verwendet die 3-Tier/3 Schichten Architektur) wird es immer wichtiger Abhängigkeiten zu minimieren.
In großen Projekten kann es leicht vorkommen, dass ein Chaos von Abhängigkeiten entsteht.
Nicht alle Abhängigkeiten lassen sich vermeiden, aber viele sind unnötig. Vor allem falsche können die Entwicklung eines Projektes aufhalten.

In den diversen Schichten(Data, Web, …) den Code unabhängig voneinander zu halten, hilft dem gesamten Prozess ungemein.
Eine Technik, um die Kopplung so gering wie möglich zu halten ist ein Inversion of Control Container. (IoC Container)

Mehr dazu in einem Artikel von Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern

Genauer eingegangen wird auf den frischen IoC Container „LightCore“ von Peter Bucher.
Wie das Wort schon sagt, ist dieser lightweight und kann mit Performance und Einfachheit punkten, muss aber nicht in Sachen Features einpacken.

Eine Feature List von Lightcore finder sich hier.
Weiter Argumente die für LightCore sprechen finden sich in einem Blogeintrag von Golo Roden.

1. LightCore – Einführung
2. LightCore – Registrierung über Xml Module
3. LightCore – Registrierung von Generics

Der Erste Teil der Einführung wird ein einfaches Beispiel mit LightCore behandeln.
Um etwas tiefer in die Materie einzusteigen wird im zweiten Teil gezeigt, wie man mit LightCore die Unabhängigkeit einer 3-Schichten Architektur verbessern kann, wie man mit dem integrierten Registrations-Modul über Xml bzw. XAML arbeitet und wie man Generics registrieren kann.

Einbinden von Lightcore

Wer auf die Entwicklungsversion zugreifen will, muss sich diese mit Subversion laden.
Diese wurde vor allem laut den Prinzipien von CCD (Clean code development) und mit einer kompletten Unit Test Abdeckung entwickelt – somit auf jeden Fall einen Blick Wert!

Für das folgende Beispiel reichen die DLLs, die es ebenfalls hier zum Download gibt.

Als Erstes müssen die gewünschten Kontrakte (Schnittstellen) registriert werden. Dies kann über zwei Varianten erfolgen:

Registrierung über Code
Registrierung über eine XML Konfigurations- Datei

Wenn die Registrierung codeseitig gewünscht ist, sollte dies in der Globalen Anwendungsdatei (Global.asax) erfolgen

Der Container wird als static member deklariert

private static IContainer _container;

In der Methode Application_Start wird der IoC Container initialisiert.

protected void Application_Start(object sender, EventArgs e)
{
    var builder = new ContainerBuilder();

Es gibt mehrere, optionale Features, die bei der Registrierung angegeben werden können. Für das Beispiel wird ein Logger registriert.

// Einfache Registrierung
builder.Register<ILogger, Logger>();
// Angabe eines Namen, um eine klare Trennung zu behalten
builder.Register<ILogger, Logger>().WithName("MyLogger");
// Angabe einer Gruppe, um bestimmte Kontrakte zu sammeln
builder.Register<ILogger, Logger>().WithGroup("MyGroup");
// Angabe von Argumenten für den Konstruktoraufruf
builder.Register<ILogger, Logger>().WithArguments("Test Argument", true);
// Gemischte Angabe
builder.Register<ILogger, Logger>().WithName("MyLogger").WithArguments("Test Argument", true);

Wenn alles registriert ist, den Container noch erstellen:

_container = builder.Build();

Die Registrierten Kontrakte können manuell über resolve aufgelöst werden

// Einfach
var myLogger = _container.Resolve<ILogger>();
//Mit Namen
var myLogger = _container.Resolve<ILogger>("MyLogger");

Lifecycle

Der Lebenszyklus besagt, ob bei jedem Anfordern einer Instanz über <Container>.Resolve<Icontract>() ein neues Objekt erstellt wird (Identisch zum new-Operator), oder das Objekt wiederverwendet werden kann.

Für die Wiederverwendung von Instanzen werden Folgende Lebenszyklen unterstützt, wobei auch weitere Lebeszyklen geschrieben werden können:

Transient
Singleton
ThreadSingleton
HttpRequest

Als Standard wird der transient Lebenszyklus verwendet. Dies besagt, dass bei jedem Aufruf eine neue Instanz der Klasse erstellt wird. Singleton würde bedeuten, dass eine einzige Instanz pro Anwendung erzeugt wird.

Der Lebenszyklus wird einmal pro Kernel wie folgt gesetzt:

builder.DefaultControlledBy<TransientLifecycle>();

Klarer weiße kann man den Lebenszyklus auch pro Registration angeben:

builder.Register<ILogger, Logger>().ControlledBy<SingletonLifecycle>();

Die Lebenszyklen können ohne Probleme beliebig erweitert werden.

Das Ergebnis

Angenommen wir haben den Logger registriert und möchten nun die Instanz in einer normalen Page Klasse

public partial class _Default : System.Web.UI.Page
{
    public ILogger Logger
    { 
        get; 
        set;
    }

In der Page Load wird der logger nun benötigt:

protected void Page_Load(object sender, EventArgs e)
{
    ILogger logger = this.Logger;
    logger.log("Page Loaded!");
}

Und wie von Magie haben wir eine Instanz der Klasse ohne direkte Erstellung auf der aktuellen Seite.

Was ist passiert?
Ein http Modul in Lightcore macht automatisch ein resolve auf die Eigenschaften, die registriert sind. Somit entfällt die manuelle Auflösung und man ist komplett vom Dependency Injection Container unabhängig.

Damit das auch klappt, muss das Modul in der Web config im Abschnitt <httpModules> hinzugefügt werden:

<httpModules>
    ...
    <add name="LightCoreDependencyInjectionModule" type="LightCore.Integration.Web.DependencyInjectionModule, LightCore.Integration.Web, Version=1.0.0.0, Culture=neutral"/>
</httpModules>

Mit ein bisschen Kreativität kann diese Vorgehensweise in allen möglichen Stellen eingesetzt werden – und schon ist man ein klein wenig Unabhängiger!

Der zweite Teil des Posts wird mit folgenden Themen in Kürze folgen: Registration über Web/App Config oder eigene Konfigurationsdatei, Einsatz in einer 3 Schichten Architektur und Registrierung von Generics!

Anbei gibt’s wie immer das oben angeführte Beispiel!

LightCore Demo: Einführung
LightCore Demo: Registerirung über Xml Module
LightCore Demo: Registrierung von Generics