typsichere NotifyPropertyChanged Linq Ausdrücke

Question

Formular mit Build your own MVVM Ich habe den folgenden Code, der uns typsicher NotifyOfPropertyChange Anrufe können:

public void NotifyOfPropertyChange<TProperty>(Expression<Func<TProperty>> property) 
{ 
    var lambda = (LambdaExpression)property; 
    MemberExpression memberExpression; 
    if (lambda.Body is UnaryExpression) 
    { 
     var unaryExpression = (UnaryExpression)lambda.Body; 
     memberExpression = (MemberExpression)unaryExpression.Operand; 
    } 
    else memberExpression = (MemberExpression)lambda.Body; 
    NotifyOfPropertyChange(memberExpression.Member.Name); 
} 

Wie funktioniert dieser Ansatz auf Standard einfache Strings vergleichen performancewise nähern? Manchmal habe ich Eigenschaften, die sich sehr häufig ändern. Kann ich diesen typsicheren Ansatz verwenden? Nach einigen ersten Tests scheint es einen kleinen Unterschied zu machen. Wie viel CPU-Speicherlast kann dieser Ansatz möglicherweise induzieren?

Answer 1

Wie sieht der Code aus, der dies auslöst? Ich vermute, es ist so etwas wie:

NotifyOfPropertyChange(() => SomeVal); 

die implizit ist:

NotifyOfPropertyChange(() => this.SomeVal); 

, die eine Erfassung von this tut, und ziemlich viel bedeutet, dass der Ausdruck Baum muss konstruiert werden (mit Expression.Constant) jedes Mal von Grund auf neu. Und dann parst du es jedes Mal. Der Overhead ist also definitiv nicht trivial.

Ist es zu viel obwohl? Das ist eine Frage, die nur Sie beantworten können, mit Profiling und Wissen über Ihre App. Es wird für viele MVC-Verwendung als OK angesehen, aber das nennt es (allgemein) nicht in einer lang andauernden engen Schleife. Sie müssen im Grunde gegen ein gewünschtes Leistungsziel profilieren.

Answer 2

Emiel Jongerius hat einen guten Leistungsvergleich der verschiedenen INotifyPropertyChanged-Implementierungen.

http://www.pochet.net/blog/2010/06/25/inotifypropertychanged-implementations-an-overview/

Unterm Strich ist, wenn Sie die Leistungsunterschiede von INotifyPropertyChanged für Datenbindung auf einem UI dann die verschiedenen Versionen ist unbedeutend verwenden.

Answer 3

Stack Walk ist langsam und Lambda-Ausdruck ist noch langsamer. Wir haben eine Lösung ähnlich dem bekannten Lambda-Ausdruck, aber fast so schnell wie String-Literal. Siehe http://zamboch.blogspot.com/2011/03/raising-property-changed-fast-and-safe.html

Answer 4

ich die folgende Methode in einer Basisklasse verwenden Umsetzung INotifyPropertyChanged, und es ist so einfach und bequem:

public void NotifyPropertyChanged() 
    { 
     StackTrace stackTrace = new StackTrace(); 

     MethodBase method = stackTrace.GetFrame(1).GetMethod(); 

     if (!(method.Name.StartsWith("get_") || method.Name.StartsWith("set_"))) 
     { 
      throw new InvalidOperationException("The NotifyPropertyChanged() method can only be used from inside a property"); 
     } 

     string propertyName = method.Name.Substring(4); 

     RaisePropertyChanged(propertyName); 
    } 

Ich hoffe, dass Sie es auch nützlich finden. :-)

Answer 5

Wie über den Defacto-Standard

if (propName == value) return; 
propName = value; 
OnPropertyChanged("PropName"); 

und dann erstellen Sie ein benutzerdefiniertes Tool, das die Code-Datei überprüft und refactors nach dieser Norm. Dieses Tool könnte eine Pre-Build-Aufgabe sein, auch auf dem Build-Server. Einfach, zuverlässig, erfüllt.

Answer 6

Typesafe und kein Leistungsverlust: NotifyPropertyWeaver-Erweiterung. Es fügt alle Benachrichtigungen automatisch vor dem Kompilieren hinzu ...