Mudu’s Blog

Letzte Woche hatte ich das Vergnügen, am MSDN TechTalk und Hands-on Lab zu Silverlight 2 dabei zu sein. Mit dem Lab wollte es leider aus technischen Gründen nicht klappen, die Speeches waren jedoch äusserst interessant. Die Präsentationen von Ronny Saurenmann und Sascha Corti stehen auf der Microsoft-Webseite bereit. Die "Hands-on Lab"-Unterlagen hat Sascha Corti in seinem Blog-Post "Silverlight 2 Beta 1 - End-to-End Hands-On Lab" veröffentlicht.

Die Speeches gaben einen Überblick über Silverlight und hoben einige Features hervor. Hier sind einige Elemente lose zusammengetragen. Interessant waren für mich besonders die Möglichkeiten bei der Arbeit mit Daten. An der Modifikation des Aussehens von Steuerelementen habe ich (persönlich) eher weniger Interesse.

• Cool fand ich das Silverlight Data Grid. Zumindest die Demonstration der Möglichkeiten war beeindruckend und ich habe ähnliche Möglichkeiten wie in der Windows-Entwicklung (kein Paging- und Postback-Käse wie im "normalen" Web). Besonders das "Inline-Editing" ist praktisch.
• Fehlen tut in der aktuellen Version (Beta 1) noch die Drop Down Box. Im Manual zum Lab ist eine Anleitung enthalten, selbst eine zu bauen, jedoch lässt sich meiner Meinung nach nicht in Minuten aus einer Text- und einer List-Box eine vollwertige Drop Down Box bauen. Das Steuerelement verhält sich, obwohl subtil, total anders als das Original. Man gehe jedoch davon aus, dass in der finalen Version eine Drop Down Box dabei sein.
• Silverlight bietet keine DataSet-Unterstützung. Der empfohlene Weg sei, eine List<T> (bzw. "Custom Objects") zu verwenden, mit dem LINQ-Helper alle geänderten Werte zu suchen und zurück an die Datenquelle (in der Regel wohl an einen Web Service) zu senden.
• Silverlight unterstützt nur asynchrone Datenabfragen (Web Service, etc.). Dies ist logisch, schliesslich würde andernfalls der Browser des Benutzers stillstehen.
• Data Binding ist weitgehend unterstützt, die Anwendung gleich wie bei der Windows Presentation Foundation (WPF). Wichtig in diesem Zusammenhang: "DataContext"- und "ItemsSource"-Properties.

Bei diesen Präsentationen sah ich auch des öfteren LINQ in Anwendung. Dies war sehr interessant, da ich noch nie damit gearbeitet habe, gehört jedoch in einen anderen Topf.

Für einen .NET-Programmierer ist Silverlight bestimmt eine schöne Sache, um "interaktive Web-Applikationen" zu entwickeln. Das Plug-In ist für den Internet Explorer, Mozilla Firefox und Safari verfügbar und unter Linux als "Moonlight" bekannt. Ich wage nicht, über die potentielle Verbreitung ein Urteil zu fällen respektive zu urteilen, ob die Unterstützung dieser Plattformen in den meisten Fällen ausreicht.

Da bleibt noch eine Frage: Warum, wieso muss das GUI von Blend so schaurig unpassend schwarz sein? Bsst, ganze Strasse dunkel, warum?

Zum Schluss noch einige Zitate zur Auflockerung:

• "In Silverlight 1 you didn't even have a text box!"
• "In this case I'd already said it's the system but I'm sure it's me who did something wrong." (der Internet Explorer verabschiedete sich abrupt)
• "There is coffee, we know how important this is for you."
• "Well, a demo application without an animation is no demo application."

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.