Mudu’s Blog

.NET Windows Forms Data Binding

November 12, 2007 on 8:44 pm | In IT, Software Development |

In den nächsten Monaten steht mir Training in .NET bevor, um in näherer Zukunft die Prüfung zum Microsoft Certified Professional im Bereich .NET-Entwicklung (MCP 70-536) ablegen zu können. Gestern habe ich mich anhand von zwei Screencasts von Paul Stovell genauer mit DataBinding auseinandergesetzt. Der Post hat ein wenig TSchoenerNotizblock-Charakter und darf nicht als fertiger Artikel gesehen werden, das ist wichtig.

Implementierung von Business Objects

Für mein Beispiel, zugegebenermassen ein “gspürsch-mi?”-Beispiel, habe ich mir die Business-Entität “Person” ausgesucht, mit den Eigenschaften “FirstName”, “LastName” und “EMail” (exposed in gleichnamigen Properties). Zusätzlich habe steht ein Flag “IsDirty” bereit, das jedoch für mein Beispiel nicht von Bedeutung ist.

Ziel ist es, nach alter OO-Weisheit, das Objekt aus der echten Welt abzubilden. Diese Person allein könnte nun in .NET bereits als Datenquelle verwendet werden, jedoch habe ich einige weitere Implementationen vorgenommen, um die DataBinding-Features auszureizen.

IEditableObject, INotifyPropertyChanged, IDataErrorInfo

Meine Person-Klasse implementiert nun explizit (!) die .NET-DataBinding-Interfaces IEditableObject, INotifyPropertyChanged und IDataErrorInfo aus dem System.ComponentModel-Namespace. Die explizite Implementierung ist nicht zwingend, es funktioniert auch so. Ich habe den Ansatz gewählt, um das fachliche Element (die Entität “Person”) vom technischen Teil (DataBinding) der Klasse sauber zu trennen.

Ein Wort zur expliziten Interface-Implementierung: Implementiere ich ein Interface explizit, stehen die entsprechenden Properties nur zur Verfügung, wenn ich meine Objektinstanz in ein Feld vom Typ des Interfaces, in unserem Falle IEditableObject, INotifyPropertyChanged oder IDataErrorInfo speichere oder in ein solches caste. Habe ich ein Feld vom Typ Person, steht die Eigenschaft nicht zur Verfügung:

// Das Error-Property ist von IDataErrorInfo gegeben und
// implementiert.
Person p = new Person();
IDataErrorInfo d = new Person();
String s = p.Error(); // funktioniert nicht
String t = ((IDataErrorInfo)p).Error; // funktioniert
String u = d.Error; // funktioniert auch

Da nun .NET Windows Forms Data Binding intern mit den Interfaces arbeitet, kann es die Methoden und Eigenschaften, die wir bereitstellen, wunderbar verwenden. Arbeite ich jedoch selbst mit einer Objektinstanz, interessieren mich die DataBinding-Elemente nicht und ich sehe sie auch nicht. Wunderbar.

Die Implementierungen und deren Zweck rolle ich an dieser Stelle nicht aus. Gerne verweise ich auf die entsprechenden MSDN-Artikel oder den Screencast von Paul Stovell in seinem Blog-Post Binding Patterns 0×0002 - Binding to Objects (englisch) mit dem geilen Kamel. Das Video habe ich mir an einem gemütlichen Sonntag Morgen bei einem Käffchen und einer Schale Corn Flakes reingezogen und in vierzig gemütlichen Minuten viel gelernt (und mich gefragt, warum ich jahrelang von Hand Text-Boxen abgefüllt habe…).

Architektur

Diese Implentierung hält die Architektur der Programms sauber. Beispielsweise sind sämtliche Validierungsroutinen dank dem IDataErrorInfo-Interface innerhalb des Business-Objekts angesiedelt und wandern nicht in den Anzeige-Layer. Und weil .NET Windows Forms Data Binding diese Interfaces out-of-the-box unterstützt, ist auch die Fehleranzeige durch einfaches Einfügen eines ErrorProviders auf der Form, der an die BindingSource gehängt wird, getan.

Der Anzeige-Layer ist dank DataBinding wirklich nur ein Anzeige-Layer und beinhaltet keinen weiteren Code. Fehlerbehandlung, Editieren mit Abbrechen und Bestätigen sowie die Aktualisierung aller Fehler läuft automatisch.