INotifyPropertyChanged - Das Elend hat (fast) ein Ende

Mit Visual Studio 2012 kommen neue Compiler und das .NET Framework 4.5 daher. Soweit nichts Ungewöhnliches. Natürlich gibt es auch jede Menge neue Sprachfunktionen und Bibliotheken. Besondere Aufmerksamkeit verdienen dabei die sog. Caller Info Attributes, die mit Visual Studio 2012 eingeführt werden und mit denen dem Entwickler ein eleganter Weg geöffnet wird, das PropertyChanged Event auszulösen.

Zur Auffrischung: Das Interface INotifyPropertyChanged stellt sicher, dass das PropertyChanged Event implementiert wird. Sind Klassen datengebunden, erfährt das Framework so, dass sich die Daten geändert haben. Im Setter eines jeden Properties muss dazu dieses Event ausgelöst werden; die Crux dabei ist allerdings, dass die PropertyChangedEventArgs dazu einen String-Parameter mit dem Namen des jeweiligen Properties verlangen.

Sollte sich im Nachhinein der Name ändern, kann wird es zu unerwartetem Verhalten kommen, wenn nicht daran gedacht wurde, auch den Magic String im Property Setter zu aktualisieren. Speziell dieses Thema ist mitunter schon viel diskutiert und auch in Form eines Coding Dojos der dotnetpro verarbeitet worden (Stichwort: “Unit Tests”).

Der folgende Code zeigt vereinfacht das klassische Vorgehensmodell:

 1:  public class Person : INotifyPropertyChanged
 2:  {
 3:     public event PropertyChangedEventHandler PropertyChanged;
 4:  
 5:     public string Name
 6:     {
 7:         get { return name; }
 8:         set
 9:         {
 10:             if (value != name)
 11:             {
 12:                 name = value;
 13:  
 14:                 // Call OnPropertyChanged whenever the property is updated
 15:                 RaisePropertyChanged("Name");
 16:             }
 17:         }
 18:     }
 19:  
 20:     private void RaisePropertyChanged(string member)
 21:     {
 22:         var handler = PropertyChanged;
 23:  
 24:         if (handler != null)
 25:         {
 26:             handler(this, new PropertyChangedEventArgs(member));
 27:         }
 28:     }
 29:  
 30:     private string name;
 31: }

 

Es ist nicht schwer sich vorzustellen, wie aufgebläht der Code wird sobald es nicht mehr nur um ein, sondern um spürbar mehr Properties geht.

Das .NET Framework 4.5 bietet hierfür eine Lösung an, indem es mit den neuen Caller Info Attributes einer aufgerufenen Methode Informationen über den Aufrufer quasi frei Haus mitzuliefert. Das folgende Beispiel verdeutlicht das anhand des CallerMemberName Attributs:

 1: protected void RaisePropertyChanged([CallerMemberName] string member = "")
 2: {
 3:   var handler = PropertyChanged;
 4:  
 5:   if (handler != null)
 6:   {
 7:     handler(this, new PropertyChangedEventArgs(member));
 8:   }           
 9: }

Der Methode RaisePropertyChanged muss nun nicht mehr der Name des Properties übergeben werden. Durch das Attribut CallerMemberName, das im NameSpace System.Runtime.CompilerServices enthalten ist, geschieht dies implizit.

Eine Möglichkeit, um nun die neue RaisePropertyChanged Methode nicht in jeder Klasse implementieren zu müssen, ist übrigens ganz einfach die Vererbung.

 1: public abstract class BaseBO : INotifyPropertyChanged
 2: {
 3:     public event PropertyChangedEventHandler PropertyChanged;
 4:  
 5:     protected void RaisePropertyChanged([CallerMemberName] string member = "")
 6:     {
 7:         var handler = PropertyChanged;
 8:  
 9:         if (handler != null)
 10:         {
 11:             handler(this, new PropertyChangedEventArgs(member));
 12:         }           
 13:     }
 14: }

 

Damit reicht es aus, die betroffenen Klassen einfach von der Klasse BaseBO abzuleiten (bei uns werden i.d.R. Fachobjekte an Views gebunden, daher der Name: BO = Business Object). Das reduziert den Aufwand für die Entwicklung von datengebundenen Klassen auf ein Minimum.

Und nun?

Und nun werden noch Wetten angenommen, ob in .NET 5 dann endlich einzelne Properties bis hin zu Klassen mit der Anweisung dekoriert werden können, dass die Properties im Falle einer Änderung das Event selbstständig auslösen sollen. AOP hat es bereits vorgemacht.

Stefan Lieser hat übrigens vor einiger Zeit in die Lambda-Trickkiste gegriffen und schon vor .NET 4.5 eine Lösung aufgezeigt, ohne Magic Strings das PropertyChanged Event auszulösen. Mehr dazu auf seinem Blog.

Stubs und Shims. Microsoft Fakes erklärt.

Microsoft geht mit der Visual Studio 11 Beta im April auf eine Roadshow durch verschiedene Großstädte. Im Rahmen der Veranstaltung werden mehrere Quick-Hit Videos veröffentlicht, die die neuen Features kurz und knackig vorstellen.

Wer interessiert ist: Vielleicht gibt es noch Tickets (die Teilnahme ist kostenlos!).

Fakes ist natürlich auch dabei. Neben den Möglichkeiten einfacher Stubs werden in dem Video auch die sogenannten Shims vorgestellt. Der Clou bei dieser Möglichkeit: Visual Studio baut die Umleitungen in die eigenen Delegate während des Compiler-Laufes direkt in den MSIL Code ein. So kann auch Code isoliert werden, der z.B. auf statische Properties aus dem .NET Framework selbst zugreift. 

Das Quick-Hit Video mit einer Übersicht über Microsoft Fakes gibt es auf vimeo zu sehen unter http://vimeo.com/40860649.

Das Microsoft Fakes Isolation Framework ist ein Mocking Framework, das als neues Feature direkt in Visual Studio 11 Beta integriert wurde, um speziell im Kontext von Unit-Tests Abhängigkeiten durch Attrappen zu ersetzen und so zu simulieren. Dadurch wird der zu testende Code sauber isoliert und kann unabhängig von anderen Komponenten und variablen Daten getestet werden. Das Quick-Hit Video  zeigt im Detail, was das bedeutet und welche Möglichkeiten Fakes dazu bereithält.

Ein Maulwurf in Visual Studio 11: Das Microsoft Fakes Isolation Framework

Mittlerweile ist die Verfügbarkeit der Visual Studio 11 Beta hinreichend bekannt. Was aber die wenigsten wissen: Unter der Haube steckt noch einiges mehr, als Microsoft aktuell bewirbt. Und dazu gehört z.B. Microsoft Moles.

Pardon. Ich meine natürlich das Microsoft Fakes Isolation Framework. Noch nie davon gehört? Das ist kaum verwunderlich. Sucht man danach im Internet, trifft man aktuell höchstens auf zwei Referenzen. Zum einen die Landing Page auf Microsoft Research für Pex & Moles und zum anderen auf die vorläufige Hilfe zu Visual Studio 11 auf MSDN. Dass letztere kaum auffindbar ist, wenn nicht gezielt danach gesucht wird, leuchtet ein. Und da die Hilfe zum jetzigen Zeitpunkt weder vollständig noch korrekt ist, stellt TOP TECHNOLOGIES hiermit das Microsoft Fakes Isolation Framework kurz vor und demonstriert mit einer funktionierenden Solution, wie man damit jetzt schon umgehen kann.

Am Ende dieses Artikels gibt es eine Zip-Datei mit der Solution zum Herunterladen.

More...

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS