Roberto's Blog : Asp.Net

ASP.NET Mvc multi Upload - Uploadify

Roberto — Tue, 18 Jan 2011 07:01:00 GMT

Als ich letzthin die Anforderung hatte, einen file upload in mvc zu machen, habe ich vergebens nach ein @Html.FileUpload oder Ähnliches gesucht.

Die Erkenntnis: So etwas gibt es in MVC nicht, da man es auch nicht braucht.

Im Prinzip geht ein FileUpload sehr einfach und zwar so:

<form id="myForm" method="post" enctype="multipart/form-data">
    <input type="file" id="FileInput" name="FileInput" />
</form>

Serverseitig kann man im Controller über Request.Files["FileInput"] auf die Datei zugreifen.

Wichtig hierbei ist der enctype des form elements. Mit Angabe des Wertes "multipart/form-data" wird der Inhalt einer jeden Datei in eine getrennte Sektion des multiparts Dokumentes gepackt. Mehr dazu gibt es in einem Post von Scott Hanselman

Auf modernen Webseiten ist ein Upload mit ggf. mehreren Dateien und Fortschrittsbalken keine Seltenheit mehr.
Eigentlich gibt es viele Plugins, die etwas in der Art machen. Die meisten basieren im Hintergrund auf die Flash Komponente swfupload, die es ermöglicht, mehrere Dateien in einem Schritt auszuwählen und hochzuladen.

Mit Hilfe eines einfachen (jQuery) Plugins - uploadify, das mehr oder weniger alles abdeckt, was so verwendet wird, ist dies keine große Sache mehr.

Dafür einfach die letzte Version herunterladen, die .js und .css Dateien einbinden

<link href="@Url.Content("~/Content/uploadify.css")" rel="stylesheet" type="text/css" />
<script src="@Url.Content("~/Scripts/jquery.uploadify.v2.1.4.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/swfobject.js")" type="text/javascript"></script>

und folgendes an der gewünschten Stelle in den HTML Markup schreiben:

<input type="file" id="FileInput" name="FileInput" />

Ein einfacher Aufruf des Plugins sieht in etwa so aus:

$('#FileInput').uploadify({
    'uploader'  : '/Content/swf/uploadify.swf',
    'script'    : '/Home/Upload',
    'cancelImg' : '/Content/Images/cancel.png',
    'folder'    : '/Uploads',
    'auto'      : true
});

Hinweis zu den Paramtern:
uploader: Das swf objekt.
script: Die MVC Controller Action.
folder: Der Pfad, in dem die Dateien gespeichert werden sollen.

Mehr dazu in der uploadify Dokumentation.

Im Controller reicht folgende Methode aus:

public string Upload(HttpPostedFileBase fileData)
{
    var fileName = Server.MapPath("~/uploads/" + System.IO.Path.GetFileName(FileData.FileName));
    FileData.SaveAs(fileName);

    return "ok";
}

Natürlich kann man als Rückgabe etwas schöneres mit Logik einbauen.

Der Übergabe Parameter muss als "fileData" benannt werden.
Ein weiterer Unterschied zu einem normalen Upload ist jener, dass mit HttpPostedFileBase und nicht HttpPostedFile gearbeitet wird.

Um ein wenig Sicherheit hinzuzufügen, wird die upload- Methode mit dem [Authorize] Attribut dekoriert.

[Authorize]
public string Upload(...)

Das Plugin meldet nun einen Fehler.
Da es aber ohne dem Authorize Attribute im Prinzip funktioniert hat, wurde durch eine Suche im Internet schnell klar, dass es sich eigentlich um einen Bug in Flash handelt der in dem Fall zur Folge führt, dass die ASP.NET Session und Autentifizierungs- Cookies nicht mitsendet werden.

Ein Workaround für dieses Problem bietet uploadify zum Glück mit dem "scriptData" Parameter, dem manuell das Authentifizierungstoken und die ASP.NET SessionId mitgegeben werden könen.

Folgendes wird im Aufruf des Plugins hinzugefügt/geändert:

var token = "@(Request.Cookies[FormsAuthentication.FormsCookieName]==null ? string.Empty : Request.Cookies[FormsAuthentication.FormsCookieName].Value)";
var sessionId = "@Session.SessionID";

$('#FileInputWithAuth').uploadify({
    ...
    'scriptData': { SessionId: sessionId, Token: token }
});

Durch die Diskussion auf StackOverFlow und dem folgenden Blog Post bin ich auf zwei Möglichkeiten gestoßen, um serverseitig die mitgegeben Parametern zu verarbeiten und in die Authentifizierungs- Logik einzubringen.

Die SessionId und das Authentifizierungscookie in der Global.asax wiedererstellen
Ein eigenes Authorize Attribut, das ebenfalls das Cookie ausliest und validiert.

Möglichkeit 1) Global.asax

In der Begin Request methode folgenden code unterbringen:

protected void Application_BeginRequest(object sender, EventArgs e)
{
    try
    {
        const string sessionParamName = "SessionId";
        const string sessionCookieName = "ASP.NET_SessionId";

        if (HttpContext.Current.Request.Form[sessionParamName] != null)
        {
            UpdateCookie(sessionCookieName, HttpContext.Current.Request.Form[sessionParamName]);
        }
        else if (HttpContext.Current.Request.QueryString[sessionParamName] != null)
        {
            UpdateCookie(sessionCookieName, HttpContext.Current.Request.QueryString[sessionParamName]);
        }
    }
    catch
    {
    }

    try
    {
        const string authParamName = "Token";
        string authCookieName = FormsAuthentication.FormsCookieName;

        if (HttpContext.Current.Request.Form[authParamName] != null)
        {
            UpdateCookie(authCookieName, HttpContext.Current.Request.Form[authParamName]);
        }
        else if (HttpContext.Current.Request.QueryString[authParamName] != null)
        {
            UpdateCookie(authCookieName, HttpContext.Current.Request.QueryString[authParamName]);
        }
    }
    catch
    {
    }
}

private static void UpdateCookie(string cookieName, string cookieValue)
{
    var cookie = HttpContext.Current.Request.Cookies.Get(cookieName) ?? new HttpCookie(cookieName);
    cookie.Value = cookieValue;
    HttpContext.Current.Request.Cookies.Set(cookie);
}

Möglichkeit B) Das eigene Attribut:

public class CustomAuthorizeAttribute : AuthorizeAttribute
{
    private const string TokenKey = "token";

    protected override bool AuthorizeCore(System.Web.HttpContextBase httpContext)
    {
        var token = httpContext.Request.Params[TokenKey];

        if (token != null)
        {
            FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(token);

            if (ticket != null)
            {
                var identity = new FormsIdentity(ticket);
                var principal = ...
            }
        }

        return base.AuthorizeCore(httpContext);
    }
}

Im Prinzip funktionieren beide Möglichkeiten einwandfrei, wobei mir persönlich das Attribut besser gefällt. Zum einen, da der code in der Global.asax jedesmal ausgeführt wird und er eigentlich nur für die speziellen asynchronen upload requests benötigt wird, zum anderen kann man die Logik im Attribut besser auslagern.

Anbei gibt’s das Beispiel mit beiden Varianten.

ASP.NET MVC multiupload mit jQuery uploadify.

ASP.NET Mvc 3 unobtrusive validation - erweitern mit eigenen jQuery Adaptern und Validatoren

Roberto — Thu, 13 Jan 2011 07:30:00 GMT

Grundsätzlich gibt es serverseitig zwei Möglichkeiten die eigenen Attribute für die Validierung zu Gestalten:

Implementierung einer Basisklasse wie RegularExpressionAttribute sowie des Interfaces IClientValidatable
Implementierung einer Basisklasse wie RegularExpressionAttribute und den Einbau eines DataAnnotationsModelValidator

Im Prinzip hat der letzte Post gezeigt, dass ein jQuery Adapter die Konvertierung von HTML5 Attributen in die für jQuery kompatiblen Metadaten vornimmt.

Diese HTML5 Attribute haben alle die selbe Form: data-val-<xxx>

Als Beispiel gibt es bereits vordefinierte Konstellationen wie data-val-regex und data-val-regex-pattern.

Somit würde der im Hintergrund stehende Adapter nichts anderes machen, als zu überprüfen, ob ein Feld mit dem Attribut data-val-regex gesetzt ist und wenn ja, das dazugehörige pattern auslesen und validieren.

Im nachstehenden Beispiel wird ein eigenes, triviales Email Attribut erstellt, um die Umsetzung etwas deutlicher zu erklären.

Möglichkeit 1) IClientValidatable

Das Attribut

public class EmailWithoutValidatorAttribute : RegularExpressionAttribute, IClientValidatable 
{ 
    public EmailWithoutValidatorAttribute() : base(@"<emailregex>")
    {

    }
 
    public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, 
                                                                             ControllerContext context)
    {
        var rule = new ModelClientValidationRule(...);
        return new[] { rule };
    }
}

Eigentlich nur ein RegularExpressionAttrubite wie von früheren Zeiten gewohnt, sowie eine zusätzliche Methode GetClientValidationRules, die die Rückgabe einer Liste von Regeln erwartet. Ob eine oder mehrere Regeln zurückgegeben werden, ist irrelevant.

Nun reicht eine normale ModelClientValidationRule für das Vorhaben nicht aus, somit wird eine eigene erstellt. Diese hat den Vorteil, dass ein eigener validationType (Der eigentliche Name des Adapters, der später benötigt wird) angegeben werden kann.

public class NamedRegexValidationRule : ModelClientValidationRule
{
    public NamedRegexValidationRule(string errorMessage,
                               string pattern, string validationType)
    {
        this.ErrorMessage = errorMessage;
        this.ValidationType = validationType;
        this.ValidationParameters.Add("pattern", pattern);
    }
}

Die im Code gezeigten ValidationParemeters können beliebig gefüllt werden, benötigt wird hier ausschließlich das Pattern.

Hinweis: Die <string, object> collection kann beliebig gefüllt werden. Letztendlich wird jedes Element als ein html Attribut data-val-<string>="<value>" gerendert. Es ist somit egal, ob "pattern" oder "blubr" vorkommt.

Die angepasste Methode im Attribut würde somit wie folgt aussehen (Wichtig ist der Name „customemail“, dieser wird als Adaptername verwendet und kann ausschließlich mit Kleinbuchstaben angegeben werden)

public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, 
                                                                         ControllerContext context)
{
    var rule = new NamedRegexValidationRule(this.ErrorMessage, this.Pattern, "customemail");
    return new[] { rule };
}

Angenommen es ist ein Model "Person" mit einer Eigenschaft "Email" vorhanden, die mit dem eben erstellen Attribut versehen ist:

public class Person
{
    [EmailWithoutValidator(ErrorMessage = "Not a valid email.")]
    public string Email { get; set; }
}

Das dazugehörige Feld als gerenderter Version @Html.TextBoxFor(p => p.Email)

<input type="text" value="" name="Email" id="Email" class="input-validation-error"
    data-val-customemail-pattern="<EmailPattern>" 
    data-val-customemail="Not a valid email." 
    data-val="true">

Zwei Sachen wurden damit erreicht:

data-val-customemail steht für die angegebene Fehlermeldung.
data-val-customemail-pattern steht für das angegebene Email Pattern.

Möglichkeit 2) DataAnnotationsModelValidator

public class EmailWithValidatorAttribute : RegularExpressionAttribute
{
    public EmailWithValidatorAttribute() : base(@"<EmailRegex>")
    {
    }
}

Nichts anderes als bei Möglichkeit 1, ohne der Implementierung des IClientValidatable Interfaces und somit der Erstellung der Regeln.

Diese werden bei dieser Variante in den Validator ausgelagert:

public class EmailValidator : DataAnnotationsModelValidator<EmailWithValidatorAttribute>
{
    private readonly string _errorMessage;
    private readonly string _pattern;

    public EmailValidator(ModelMetadata metadata, ControllerContext context, EmailWithValidatorAttribute attribute) 
                       : base(metadata, context, attribute)
    {
        this._errorMessage = attribute.ErrorMessage;
        this._pattern = attribute.Pattern;
    }

    public override IEnumerable<ModelClientValidationRule> GetClientValidationRules()
    {
        var rule = new NamedRegexValidationRule(this._errorMessage, this._pattern, "customemail");
        return new[] { rule };
    }
}

Auch hier gibt es eine Methode GetClientValidationRules(), die eigentlich die selbe Logik beinhaltet, wie in Möglichkeit 1.

Zusätzlich muss der Validator nun in der Global.asax (In der application start Methode) noch mit Angabe des Attributes registriert werden:

DataAnnotationsModelValidatorProvider.RegisterAdapter(
                            typeof(EmailWithValidatorAttribute), 
                            typeof(EmailValidator));

Im Prinzip bringen beide Möglichkeiten das selbe Ergebnis, Möglichkeit 1 hat den Nachteil (zumindest für den ein oder anderen), dass die Logik direkt im Attribut steht und Möglichkeit 2 lagert dies in einen externen Validator aus. Somit ist das Attribut nicht MVC abhängig und könnte auch für andere Zwecke verwendet werden, bzw. bereits vorhandene Attribute könnten problemlos wiederverwendet werden.

Last but not least, der clientseitige Aufbau des Adapters.

Die jQuery unobtrusive validation Bibliothek stellt eine Methode Add() zur Verfügung, über welche neue, eigene Adapter registiert werden können. Diese nimmt als Parameter einmal den Adapternamen, den/die Attributnamen die benötig werden, sowie eine Funktion, über die die eigene Logik implementiert werden kann.

jQuery.validator.unobtrusive.adapters.add("customemail", ["pattern"], function (options) {

    if (options.element.tagName.toUpperCase() == "INPUT") {

        // Set the regex rule with the given pattern.
        options.rules["regex"] = options.params.pattern;

        if (options.message) {
            options.messages["regex"] = options.message;
        }
    }
});

Wie im letzten Post gezeigt, beinhaltet das options Objekt Regeln, Parameter und Mitteilungen, über die die Validierung gesteuert wird.

In Falle einer Email Validierung reicht eine regex Regel aus, es können aber beliebig viele hinzugefügt werden. Wichtig ist hierbei nur, dass diese als Paremter angegeben werden ["pattern", "<anderes Attribut">, ...]

Natürlich macht es nicht wirklich viel Sinn, ein Email Attribut so kompliziert zu gestalten, viel mehr geht es darum zu zeigen, wie es im Verhältnis doch einfach ist, eigene Adapter zu erstellen. Im Web 2.0 Zeitalter ist eine kombination aus client und server Validierung eher Standard als eine Ausnahme. Mit ein bisschen Mühe können tolle Sachen, wie bspw. eine Überprüfung, ob ein Username einzigartig ist entwickelt werden. Der Große Vorteil liegt auch hier in der Entkoppelung der Validierungslogik vom restlichen Teil der Anwendung.

Anbei gibt’s wie immer das Beispiel zum Post.

ASP.NET MVC 3 unobstrusive custom validation sample.

ASP.NET unobtrusive validation - Clientseitige Adapter

Roberto — Mon, 27 Dec 2010 13:15:00 GMT

Wie bereits im letzten Post beschrieben, gibt es seit der dritten Version des MVC Frameworks die Möglichkeit, Formular Validierungen über HTML 5 kompatible Attribute zu machen.

Diese werden clientseitig über Adapter umgesetzt, die die entsprechenden Parameterwerte aus den HTML 5 Attributen in die für jQuery Validate vorgesehenen Metadaten konvertieren.

In diesem Post wird nicht genauer auf das jQuery Validate Plugin eingegangen, sondern mehr über die Logik und Konvertierungsmechanismen der Adapter.

Mehr Informationen zu jQuery Validate finden sich hier.

Als weiteres, für den Post relevanteres Plugin findet sich das jQuery.validator.unobtrusive.adapters.js im Ordner Scripts eines jeden MVC3 Projekttemplates.

Im Script gibt es eine Registrierungsmethode "add", sowie einige allgemeine Methoden "addBool", "addSingleVal" und "addMinMax".

Im Grunde sind die meisten Fälle damit abgedeckt, als Beispiel ein Auszug aus der eben genannten Datei:

adapters.addBool("creditcard").addBool("date").addBool("digits").addBool("email").addBool("number").addBool("url");
adapters.addSingleVal("accept", "exts").addSingleVal("regex", "pattern");
adapters.addMinMax("length", "minlength", "maxlength", "rangelength").addMinMax("range", "min", "max", "range");

Bevor genauer auf die einzelnen Methoden eingegangen wird, eine kurze Erklärung zur Methode "add", die intern von jeder aufgerufen wird:

adapters.add = function (adapterName, params, fn)
{
....
}

adapterName: Ist der Name des zu hinzuzufügenden Adapters. Im Prinzip nichts anderes, als der im Attribut data-val-<Name> vorkommenden Platzhalter.

params: Ist ein optionales Array aus Parametern, die aus den Attributen data-val-<Name>-<Paremter> extrahiert werden.

fn: Ist die Funktion, welche die Werte der Html Attribute in die für "jQuery Validate" benötigten Regeln und/oder Mitteilungen konvertiert.

Die Methode addBool macht somit einen in etwa ähnlichen Aufruf:

add("email", function(options) {
    ...
    options.rules["required"] = true;
    ...
});

Hinweis: Das option Element beinhaltet folgende Werte:

element: Das HTML Element dem der Validator zugeordnet ist.

form: Das HTML Form Element.

message: Die Ausgabe, die ebenfalls aus den HTML Attributen extrahiert wird.

params: Ein Array Element mit Werten, die aus den HTML Attributen extrahiert werden. (Bspw. var min = options.params.min)

rules: Das Array Element, das die Namen und Werte beinhaltet, die wiederum für die jQuery Validate Regel benötigt werden. (Bspw. ["required"] = true)

messages: Ein Array Element, das die Namen und Werte beinhaltet, wobei der Name für die verletze Regel und der Wert für die dazugehörige Ausgabe stehen. (Bspw. ["required"] = "Das Feld darf nicht leer sein.")

Nun sollte auch die addSingleValue anhand eines Beispiels verständlich werden:

adapters.addSingleVal("regex", "pattern");

Gegeben ist ein HTML Element, wobei die Eingabe nicht leer sein kann und es nur Großbuchstaben beinhalten darf. (= dem Regex [A-Z] enstprechen).

<input ... 
data-val="true"
data-val-required="Das Feld darf nicht leer sein."
data-val-regex="Das Feld darf nur Großbuchstaben beinhalten."
data-val-regex-pattern="[A-Z]" />

Folgende Werte würden daraus entstehen:

-> options.rules["required"] = true
-> options.rules["regex"] = "[A-Z]"
-> options.messages["required"] = "Das Feld darf nicht leer sein."
-> options.messages["regex"] = "Das Feld darf nur Großbuchstaben beinhalten."

Und natürlich würde auch addMinMax nichts anderes machen, als ein paar "rules" wie bspw. "min", "max" zu setzen.

Am Besten einfach ein paar Testelemente machen und mit der Firefox Extension Firebug ansehen.

Im nächsten Teil wird dann genauer auf die Erstellung eigener Adapters eingegangen!

ASP.NET Mvc 3 unobtrusive validation

Roberto — Sun, 26 Dec 2010 10:55:00 GMT

In dieser dreiteiligen Postreihe wird gezeigt, wie sich ab ASP.NET Mvc 3 die Validierung von Formularen geändert hat, welche Vorteile sie mit sich bringt und wie die Validierung mit eigenen Regeln erweitert wird.

Bereits in MVC2 gab es eine client und serverseitige Validierung für Models.
Standartmäßig für den Client mit ASP.NET Ajax, aber auch mit einer kleinen jQuery Erweiterung machbar.

Bereits durch dieses Verfahren wurde der serverseitige Teil (Durch den Einsatz von DataAnnotations) vom Clientseitigen entkoppelt.

public class Mandant
{
    [Required(ErrorMessage = "Name is required.")]
    [StringLength(50, ErrorMessage = "Must be under 50 characters.")]
    [DisplayName("Mandant Name")]
    public string Name { get; set; }
}

Was im Html Code dabei gerendert wird, sieht in etwa so aus:

//<![CDATA[
if (!window.mvcClientValidationMetadata) { window.mvcClientValidationMetadata = []; }
window.mvcClientValidationMetadata.push({"Fields":[{"FieldName":"Mandant.Name","ReplaceValidationMessageContents":true,"ValidationMessageId":"Mandant_Name_validationMessage","ValidationRules":[{"ErrorMessage":"Name is required.","ValidationParameters":{},"ValidationType":"required"},{"ErrorMessage":"Must be under 50 characters.","ValidationParameters":{"minimumLength":0,"maximumLength":50},"ValidationType":"stringLength"}]}, ...
//]]>

Ab der dritten Version des MVC Frameworks wird die Validierung hingegen etwas schicker gelöst.

Im Prinzip bringt die Neuerung den Vorteil mit sich, dass auf einen langen JSON String im Html code verzichtet wird und dafür auf HTML5 kompatible Attribute gesetzt wird, die die Validierung der Input Felder beschreiben.

<input type="text" value="" name="Name" id="Name" data-val-required="The Name field is required." data-val="true" class="input-validation-error">
<input type="text" value="" name="Age" id="Age" data-val-required="The Age field is required." data-val-number="The field Age must be a number." data-val="true" class="input-validation-error">

Ein weiterer Vorteil ist der Verzicht auf automatisch generierte IDs, da die Informationen nun direkt am Input Feld angefügt werden.

Um diese "unobtrusive" (Übersetzt: unauffällig, bescheiden) Validierung nutzen zu können, sind zwei einfache Schritte notwendig.

Folgende Script Bilbiotheken einbinden:

(Beim erstellen eines neuen MVC3 Projekts werden diese standartmäßig eingebunden)

<script src="@Url.Content("~/Scripts/jquery-1.4.1.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.unobtrusive-ajax.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.min.js")" type="text/javascript"></script>

Dazu noch sicherstellen, dass in der Web.Config folgende Einstellungen gesetzt sind:

<appSettings>
    <add key="ClientValidationEnabled" value="true"/> 
    <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
</appSettings>

Diese sind ebenfalls ab einem MVC3 Projekt-Template standartmäßig dabei, bei einem Upgrade von einer älteren Version müssen sie manuell hinzugefügt werden.

Die eben genannten Einstellungen sind Global für das ganze Projekt, natürlich gibts diese auch Kontext spezifisch:

HtmlHelper.ClientValidationEnabled = true;
HtmlHelper.UnobtrusiveJavaScriptEnabled = true;

Dazu wie gewohnt das Model mit den DataAnnotations versehen (siehe weiter oben) und das Ganze sollte funktionieren.

Und wie das Ganze im Hintergrund funktioniert?

Grundsätzlich hängt alles davon ab, ob das data-val="true" Attribut gesetzt ist.
Dieses wird dem Feld hinzugefügt, wenn mindestens eine Regel aktiv ist.
Die wohl am meisten verwendete Regel ist jene, die besagt, ob ein Feld ein Pflichtfeld ist. (Html Attribut dazu: data-val-required="true")
Natürlich gibt es zusätzlich verschiedene optionale Attribute wie data-val-length, data-val-length-min (max), data-val-range-min (max), data-val-regex, data-val-regex-pattern, usw.

Fazit:

Ich habe bereits ein Projekt umgestellt, es geht relativ fix und ist doch um einiges schöner - somit: man sollte sich die Arbeit antun.

Im nächsten Post wird genauer auf eigene jQuery Validators eingegangen, schaut also vorbei :-)

Anbei wie immer das Beispiel:

ASP.NET MVC 3 unobstrusive validation sample.

MVC Html Helper á la Fluent Interface

Roberto — Tue, 08 Jun 2010 21:45:00 GMT

Helferlein können das Leben ganz schön vereinfachen.

Das zeigt sich an diversen Beispielen. Wer hat sich noch nicht eine LabeledTextbox oder ein Control in der Art in klassischen Webforms fabriziert, um sich damit eine Menge Tipparbeit zu sparen?

Natürlich geht das auch mit MVC.

Ist es nicht cool, wie Telerik und Co. Das machen?

<%= Html.MeineSuperAnwendung().MeinMegaControl().DasAllesKann %>

Korrekt! Die eierlegende Wollmilchsau unter den eigenen Controls kann das!

Wie das geht?

Ganz einfach: Man nehme eine statische Klasse, die das Control instanziert und zurückgibt.

Die fluent Schreibweise ist nichts anderes als eine Methode, die das eigene Objekt zurückgibt.

Gegeben eine Klasse Button mit folgender Methode:

public Button IchBinEinFluentDing()
{
    return this;
}
var button = new Button().IchBinEinFluentDing().IchBinEinFluentDing()

Klingt nicht nur simple, ist es auch. Gut, nicht ganz, ein Zwischenschritt wird noch benötigt.

Die „Container“ Klasse, die die einzelnen Controls zurückgeben kann. Somit wird nicht auf ein Controltyp beschränkt.

public class MyHtmlHelpers
{
    private HtmlHelper _helper;
    public MyHtmlHelpers(HtmlHelper helper)
    {
        this._helper = helper;
    }
    public CoolButton CoolButton(string text)
    {
        return new CoolButton(this._helper, text);
    }
    ...
}

Wie bereits verraten, die statische Klasse (Extension), die die Helpers zurück gibt:

public static class MyProductExtension
{
    public static MyHtmlHelpers MyProduct(this HtmlHelper helper)
    {
        return new MyHtmlHelpers (helper);
    }
}

Lange Rede – kurzer Sinn:

Html.MyProduct().CoolButton()

Gut, die Schreibweise ist klar, aber das Ganze macht noch keinen Sinn. Der Button muss her!

public class CoolButton
{
    private IDictionary<string, object> _attributes;
    private string _text;
    private HtmlHelper _helper;
    public CoolButton(HtmlHelper helper, string text)
    {
        this._text = text;
        this._helper = helper;
        this._attributes = new Dictionary<string, object>();
    }

Ein Text für den Button, das html helper objekt - das später benötigt wird und das Kernstück – die Attribute. Das ganze Ding soll ja letztendlich flexibel sein.

public CoolButton SetAttribute(string key, object value)
{
    if (!this._attributes.ContainsKey(key))
    {
        this._attributes.Add(key, value.ToString());
    }
    return this;
}

Natürlich soll der Button auch navigieren können – Angaben á la MVC + Id:

public CoolButton RouteTo(string controller, string action, object itemId)
{
    var urlHelper = new UrlHelper(this._helper.ViewContext.RequestContext);
    string url;
    if (itemId == null)
    {
        url = urlHelper.Action(action, controller);
    }
    else
    {
        url = urlHelper.Action(action, controller, new { id = itemId });
    }
            
    this._attributes.Add("onclick", string.Format("window.location='{0}';return false;", url));
    return this;
}

Natürlich macht es nicht immer Sinn ein onclick event zu haben, aber es soll ja letztendlich der Sinn der Attribute erklärt werden.

Es können weitere solcher Methoden folgen, bspw. Um die css Klasse oder ein client event zu setzen.

Last but not least – Rendern.
Aufgrund des Attribute Dictionarys recht einfach: Stück für Stück zusammensetzen.

public string Render()
{
    var attributeBuilder = new StringBuilder();
    foreach (KeyValuePair<string, object> attribute in _attributes)
    {
        attributeBuilder.AppendFormat(" {0}=\"{1}\"", attribute.Key, attribute.Value);
    }
    return string.Format("<button {0}>{1}</button>", attributeBuilder.ToString(), this._text);
}

Für jedes KeyValuePair des Dictionarys wird folgendes Konstrukt erstellt: Key=“Value“, onclick=“TuWas();“

Das Ganze sieht dann in etwa so aus:

<%= Html.MyProduct().CoolButton("Edit")
                        .SetAttribute("class", "editButton")
                        .RouteTo("User", "Edit", Model.User.Id)
                        .Render() %>

Man kann darüber streiten, ob eine Fluent Schreibweise wie eben beschrieben Sinn macht, ob sie sauber ist, oder ob sie nur ein Workaround ist, bis etwas Neues Erfunden wird?

In ASP.NET Webforms Zeiten hab ich mir teilweise meine Controls per Render Überschreibung mit dem Writer selbst erzeugt (Fragt jetzt nicht warum – ich wollte einfach die Kontrolle über das Ding haben ;-) ). Das ist ja ebenfalls suboptimal und im Gegensatz dazu sind HTML Helpers ein Genuss :-)

Anbei gibt’s wie immer ein etwas ausführlicheres Beispiel.

ASP.NET MVC Html Helpers sample

Abstraktion

Roberto — Mon, 01 Mar 2010 08:37:00 GMT

Am 13. Oktober 2008 haben Peter Bucher und Golo Roden unter dem Titel "Noch Fragen, Bucher? Ja, Roden!" angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Heute, am 1. März 2010, ist es nun wieder so weit, und das Thema für diesen Monat lautet:

Abstraktion

Die beiden haben mich netterweise gefragt ob ich dieses Mal als "Gast-Mitstreiter" dabei bin, und so haben wir drei uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters und Golos Kommentare finden sich zeitgleich in ihren Blogs, folgend nun meine Meinung zu diesem Thema:

Das Prinzip der Abstraktion ist im Grunde nichts anderes als das Weglassen von Einzelheiten und das Überführen auf etwas Allgemeines oder Einfacheres (Generalisieren). So jedenfalls die Definition.

Auch in der Objektorientierten Programmierung findet dieses Prinzip Einsatz. Durch die Abstraktion von Aktionen oder Eigenschaften wird versucht, Redundanzen zu vermeiden.

Außerdem vereinfacht uns Abstraktion das Leben durch Verringerung der Komplexität.

Beispiele für Abstraktion

Auslagerung von Codezeilen in eine benannte (zentralere) Funktion
Einführung von generischen Klassen
Unterklassen
Interfaces
Vererbung
Modularisierung der Anwendung
…

Grundsätzlich wird in der Software Programmierung zwischen zwei Arten der Abstraktion unterschieden:

Funktionale Abstraktion (Control abstraction)

In der funktionalen Abstraktion wird eine Anwendung an Hand von funktionalen Merkmalen in individuelle Komponenten aufgebrochen, wobei die einzelnen Komponenten jeweils eine logisch-semantisch zusammengehörige Einheit bilden.

Bspw. so eine drei Schichten Architektur

Jede der einzelnen Schichten erfüllt eine bestimmte Funktion und auf diese sollte sie sich beschränken. Wie das intern abgehandelt wird, interessiert einzig und allein diese selbst.

Die Grafik zeigt die Präsentationsschicht (bspw. Website), die auf die Business Logik zugreift um bspw. eine Auflistung aller Kunden zu bekommen. Wenn ein Entwickler das grafische UI programmiert, sollte er die Möglichkeiten der Business Schicht verstehen, aber nicht deren internen Aufbau.

Die Business Schicht wiederum dient als Schnittstelle zur Datenschicht. Sie beinhaltet lediglich Services, die die gewünschten Daten aus der Datenschicht holen und zur Verfügung stellen. In welcher Art und Weiße die Daten geholt werden, ist, wie weiter oben bereits erwähnt, der Präsentation egal.

Woher die Daten kommen, ob und welche Datenbank verwendet wird, welcher OR Mapper im Einsatz ist, … interessiert nur die Datenschicht.
Alle Schichten sind voneinander unabhängig. Dies senkt die Komplexität der Anwendung und vereinfacht das ändern zentraler Funktionalitäten.

Wenn gesagt wird: Belästige mich nicht mit Details – wird versucht zu abstrahieren.

Datenabsraktion (Data abstraction)

Das klassische Beispiel hierfür sind mehrere Entitäten

Jede dieser einzelnen Entitäten beinhaltet Standartfelder wie Id, Erstell- und Änderungsdatum.

Es wäre suboptimal diese getrennt in den einzelnen Entitäten einzufügen. Viel besser ist eine etwas mehr zentralere Klasse (Entity), die bestimmte, für alle gemeinsame Eigenschaften beinhaltet um somit ein wenig Redundanz zu vermeiden.

In C# werden mit dem „abstract“- Modifizier(in vb.Net MustInherit) zentrale Klassen erstellt, sprich sie dienen nur als Basisklassen und müssen implementiert werden.

Wie viel Abstraktion ist zu viel Abstraktion?

Je detailreicher die Strukturen bzw. Modelle werden (je weniger Abstraktion sie verwenden), desto besser ist die Akzeptanz. Je weniger Details die einzelnen Modelle der Anwendung beinhalten (je mehr Abstraktion sie verwenden), desto größer ist die Flexibilität und Wiederverwendbarkeit.

Das Abstraktionsprinzip besagt, Abstraktion sollte dann verwendet werden, wenn damit Redundanzen (üblich im Code) vermieden werden können.
Die Softwareentwicklung strebt ja bekanntlich nach immer höheren Stufen der Abstraktion. Aber mehr ist nicht immer besser. Wer ganze Stockwerke aus Abstraktionsebenen baut, vergisst, dass diese nicht nur von Maschinen betreten werden.

Mehrere Abstraktionen bedeuten meist einen höheren Aufwand und sind außerdem schwieriger zu verstehen.

Zu Beginn eines Projektes sind Abstraktionen teilweise schnell implementiert, allerdings müssen sich diese erst bewähren:
Wird in einem späteren Projektzyklus klar, dass eine Abstraktion nicht korrekt ist, können sehr hohe Änderungskosten anfallen – ein Alptraum für jeden Entwickler.

Um ein neues Problem zu lösen gerät mancher Entwickler in die Versuchung eine zusätzliche Abstraktionsschicht einzubauen. Abstraktionen an sich sind nicht das Problem, sondern vielmehr die (zu komplexe oder falsche) Denkweise des Entwicklers, der sich damit zusätzliche Probleme einfängt.

Ein Beispiel dazu:

Zwei Entitäten Kunden und Benutzer sind gegeben. Jetzt fällt einem Entwickler ein, dass beides Personen sind und beide das Feld Name haben. Es ist eine Basisklasse „Person“ gegeben und das „Name“ Feld wird dorthin verschoben.
Jetzt kommt ein weiterer Entwickler, der der Meinung ist, dass das Feld „Name“ bei bestimmten Kunden eigentlich die Kundennummer ist und abstrahiert das Feld zu „Kundennummer“.
Was zurück bleibt ist eine nicht mehr klare Bedeutung der einzelnen Felder.

Mein Fazit

Wie bei so vielem im Leben ist auch hier eine gesunde Mischung gefragt.
Abstraktion gehört zu den Urbausteinen der Softwareprogrammierung. Heute wäre es nahezu undenkbar eine Anwendung ohne zu entwickeln.

Wie viel Abstraktion verwendet wird, hängt von vielen Faktoren ab. Unter anderem den Anforderungen, der Erfahrung des Teams, Erweiterbarkeit, etc.
Wenn bspw. von Anfang an vorgesehen wird, dass ein Kunde ein Verkäufer werden kann, sollte vielleicht auch vorgesehen werden, dass dieser zu einem Mars Mensch mutieren kann.
Klar, diese „neverending abstraction“ ist immer eine Frage des Aufwands.

Ich kenne die Frage sehr wohl, was man wie in Zukunft machen könnte oder vorsehen sollte. In den meisten Fällen hat sich herausgestellt – Eierlegende Wollmilchsäue sind nur selten die Beste Lösung. Abstraktion ist dafür gedacht, die Komplexität einer Anwendung zu verringern und nicht in den Sternen zu treiben.

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

Dynamic Objects in C# 4.0

Roberto — Tue, 24 Nov 2009 00:00:00 GMT

Eine neues Feature in C# 4 ist die „Dynamic Language Runtime“ (DLR). Mit dem „dynamic“ Schlüsselwort ist es möglich zur Laufzeit Properties und Methoden an Objekten zu binden. Dabei gibt es allerdings keinerlei Überprüfung ob diese auch existieren – dafür erhöht sich die Flexibilität der Anwendung.
Eigene Klassen können durch die Implementierung des DynamicObject und durch die Überschreibung der gewünschten Methoden erstellt werden.

Ein praktisches Beispiel dazu:
Wer kennt das Problem nicht, es gibt eine Javascript Komponente die im Header der Seite einiger Einstellungen bedarf. Diese möchte man aber nicht per Javascript, sondern per Asp.Net setzen. Ist ja kein Problem, aber jede einzelne Property Serverseitig abzubilden kostet viel Zeit, insbesondere wenn die Komponente ständig weiterentwickelt wird.

Das Ausgabe sollte in JavaScript etwa so aussehen:

var myObject = new JavaScriptComponent();
myObject.width = 400;
myObject.show = false;
…

Dynamic to the rescue!
Wie oben beschreiben ist es möglich an dynamischen Objekten beliebige Properties und Methoden zu binden.
Dafür einfach eine Klasse ClientScriptCreator die von DynamicObject ableitet.

public class ClientScriptCreator : DynamicObject

Um die dynamischen Properties zu speichern wird ein Dictionary verwendet

Dictionary<string, object> _members;

Für die Benennung der clientseitigen Klasse und des Objekts werden zwei weitere Member deklariert

string _clientClassName;
string _clientObjectName;

Die drei Member werden nun im Konstruktor der Klasse übergeben/gesetzt

public ClientScriptCreator(string clientClassName, string clientObjectName)
{
    _members = new Dictionary<string,object>();
    _clientClassName = clientClassName;
    _clientObjectName = clientObjectName;
}

Mit der Überschreibung der Methode TrySetMember werden die Properties (falls noch nicht vorhanden) in das Dictionary gespeichert.
Diese liefert einen SetMemberBinder und ein Objekt mit dem Wert.

public override bool TrySetMember(SetMemberBinder binder, object value)
{
    if (!_members.ContainsKey(binder.Name))
    {
        _members.Add(binder.Name, value);
        return true;
    }
    else
    {
        return false;
    }
}

Ähnlich dazu gibt es die TryGetMember Methode, welche den gesetzten Wert (falls vorhanden) zurückgibt

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
    if (_members.ContainsKey(binder.Name))
    {
        result = _members[binder.Name];
        return true;
    } 
    result = null;
    return false;
}

Nun ist die Klasse im Stande dynamisch Properties zu setzen und zurück zu geben.

dynamic clientScriptCreator = new ClientScriptCreator();
clientScriptCreator.PropertyOne = "'Some string'";
clientScriptCreator.PropertyTwo = "false";
clientScriptCreator.PropertyThree = "4711";

Das client Script muss nun zusammengesetzt werden um in den Header geschrieben zu werden.
Dafür eine Methode GetDefaultScript die den Dictionary Member durchläuft und diesen in ein <script type=“test/javascript“> Konstrukt wiedergibt.

private string GetDefaultScript()
{
    StringBuilder sb = new StringBuilder();
    sb.Append("<script type=\"text/javascript\">" + Environment.NewLine);
    sb.Append(_clientObjectName + " = new " + _clientClassName + "();" + Environment.NewLine);
    foreach (KeyValuePair<string, object> kvp in _members)
    {
        sb.Append(_clientObjectName + "." + kvp.Key + " = " + kvp.Value + ";" + Environment.NewLine);
    }
    sb.Append("</script>");
    return sb.ToString();
}

Das Script soll anschließend in einem Literal Control im head Bereich der Seite stehen

<head>
    </asp:Literal ID="ClientScriptLiteral" runat="server">
</head>

Was noch fehlt ist der Aufruf der Methode, die das client Script zurückgibt.
Dafür die TryInvokeMember überschreiben, damit dynamische Methoden aufgerufen werden können. In dem folgenden Abschnitt wird auf die Methode „ToDefaultScript“ überprüft – wenn diese vorkommt, wird das Script zurückgeliefert:

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
    if (binder.Name == "ToDefaultScript")
    {
        result = GetDefaultScript();
        return true;
    }
    result = null;
    return false;
}

In der Page_Load der Seite erfolgt der Aufruf wie folgt

ClientScriptLiteral.Text = clientScriptCreator.ToDefaultScript();

Das Ganze ist nun wirklich dynamisch. Wird die JavaScript Komponente weiter entwickelt, braucht man sich nicht mehr darum zu kümmern und kann die Objekte wo gewünscht einfach erweitern.

Anbei gibt’s noch das Beispiel als Visual Studio 2010 Projekt dazu.