2015-05-29 7 views
9

Hier ist eine DynamicDataObject Klasse abgeleitet von DynamicObjectDynamic verhält sich anders für Nullwerte

public class DynamicDataObject : DynamicObject 
{ 
     private readonly Dictionary<string, object> _dataDictionary = new Dictionary<string, object>(); 

     public override bool TryGetMember(GetMemberBinder binder, out object result) 
     { 
      return _dataDictionary.TryGetValue(binder.Name, out result); 
     } 

     public override bool TrySetMember(SetMemberBinder binder, object value) 
     { 
      if (!_dataDictionary.ContainsKey(binder.Name)) 
      { 
       _dataDictionary.Add(binder.Name, value); 
       return true; 
      } 

      return false; 
     } 

     public override IEnumerable<string> GetDynamicMemberNames() 
     { 
      return _dataDictionary.Keys; 
     } 
    } 

und ich bin raubend DynamicDataObject wie unten.

public MainWindow() 
{ 
    InitializeComponent(); 
    dynamic person = new DynamicDataObject(); 
    person.FirstName = "Vimal"; 
    person.LastName = "Adams"; 
    person.Address = null; 
} 

kann ich alle Mitglieder person sehen und es ist Wert im _dataDictionary aber die Debugger Ansicht schließt Mitglieder mit null Wert zugleich. So dass person.Address Mitglied ist nicht sichtbar in der dynamischen Ansicht Sammlung. (Bitte sehen Sie die folgenden Screenshot). Kann mir bitte jemand helfen, zu verstehen, warum sich DynamicObject in diesem Szenario anders verhält?

enter image description here

Antwort

3

Ich denke, es ist nur eine Optimierung. Es macht keinen Sinn, einen Verweis auf den Standardwert des Typs beizubehalten. Es gibt nur default(T) zurück, wenn Sie versuchen, darauf zuzugreifen.

Es verhält sich wie ein Wörterbuch:

string property = "Address"; 
object val; 

if (!dic.TryGetValue(property, out val)) 
{ 
    return default(T); 
} 
else 
{ 
    return (T)val; // simplification 
} 

Was ist der Punkt hier ist Address im Wörterbuch zu halten? Keiner. Deshalb ist es entfernt.

+0

Irgendein Punktentwickler muss eine Eigenschaft absichtlich auf null setzen. Das bedeutet nicht, dass es wegen einiger Optimierung nicht in der Liste angezeigt werden sollte. Dann sollte das gleiche Verhalten funktionieren, wenn wir auch LINQ schreiben. Es zeigt auch Member des Werttyps, wenn ich eine int-Eigenschaft mit dem Standardwert 0 setze. Also ist deine Annahme falsch zB: person.Age = 0 –

+0

Ich dachte das gleiche, also teste ich es. Es scheint nur nach "null" zu suchen. –