Ja, ich gebe es offen und ehrlich zu! Ich habe sie noch nie wirklich genutzt, die ASP.NET WebForms ObjectDataSource. Irgendwie hatte ich ein Unbehagen bei der Vorstellung mir das alles bloß zusammen zu klicken und habe daher bisher einen Bogen um die ObjectDataSource gemacht. Außerdem habe ich bisher auch noch niemanden getroffen, der ernsthaft in Erwägung gezogen hätte die ObjectDataSource zu nutzen - oder sich zumindest getraut hätte, dies zuzugeben ;-)

Kürzlich war es dann aber soweit. meine Für eine kleine Demo startete ich damit, die serverseitige ASP.NET MVC Implementierung meiner Beispielanwendung für meinen jQuery Vortrag auf der dotnet Colgone nach Webforms zu konvertieren. Mein Ziel war es dabei, wo immer es nur geht, den WebForms “Baukasten” zu nehmen. Da ich bereits einen bestehenden Business Service hatte, der mir meine Objekte laden und persistieren konnte, kreuzte sie nun also meinen Weg, die ObjectDataSource.

Nach ein paar Klicks durch den Wizzard und einem beherztem F5 bestätigte sich vorerst mein initiales Vorurteil: “Totaler Mist!”.

Mein Business Service hatte nämlich eine Abhängigkeit auf eine weitere Klasse, die für die Datenhaltung zuständig war. Diese Abhängigkeit fand sich in meinem Quellcode in Form eines Konstruktor Parameters wieder. In meiner ASP.NET MVC Implementierung war der DI Container StructureMap für das Auflöösen dieser Abhängigkeit zuständig.

Die WebForms Variante brach die Ausführung des Codes nun allerdings mit einer Exception ab und wies mich in freundlichem Gelb darauf hin, dass mein Business Objekt keinen parameterlosen Konstruktor hätte.

In der Hoffnung, eine Factory für mein Business Objekt angeben zu können durchsuchte ich also die Eigenschaften der ObjectDataSource. Leider wurde ich nicht fündig, fluchte ein wenig darüber, dass meine Anforderung doch gar nicht so ungewöhnlich wäre und beendete Visual Studio frustriert.

Glücklicherweise guckte ich ein wenig später doch noch mal nach einer Lösung. So kann zwar keine Eigenschaft für eine Factory angegeben werden, stattdessen wird jedoch ein Ereignis zur Verfügung gestellt, in dem ich das entsprechende Business Objekt erstellen und meiner ObjectDataSource zuweisen kann.

Konkret sieht dies wie folgt aus:

protected void AufgabenDataSource_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
   AufgabenService service = ObjectFactory.GetInstance<AufgabenService>
   e.ObjectInstance = service;
}

Nun habe ich über die ObjectFactory zwar einen direkten Verweis innerhalb meiner CodeBehind Datei auf den genutzten DI Container (in meinem Fall StructureMap), dies ist mir aber immer noch lieber, als die Abhängigkeit zur Persistenzschicht in meinem Business Service hart zu verdrahten.

Und die Moral von der Geschicht …

… lautet: Erst ausprobieren und dann (gegebenenfalls) meckern ;-)