Beim Spielen mit Reflektion im neuen .NET Framework 4.5 stieß ich auf ein seltsames Verhalten, das ich ziemlich unerwartet fand. Der Namespace System.Reflection bietet einige neue Erweiterungsmethoden zum Ausnutzen von Type-Objekten. Zwei davon sind GetRuntimeProperty (String-Name) und GetRuntimeProperties().Reflection: inkonsistentes Framework-Verhalten mit GetRuntimeProperty-Methoden
Stellen Sie sich nun vor, Sie hätten ein einfaches Objekt mit einer internen Eigenschaft.
public class ObjectBase
{
protected int Id { get; set; }
public string Name { get; set; }
}
Und Sie versuchen jetzt, diesen Typ auszunutzen.
var properties = typeof(ObjectBase).GetRuntimeProperties();
// properties.Count = 2
var idProperty = typeof(ObjectBase).GetRuntimeProperty("Id");
var nameProperty = typeof(ObjectBase).GetRuntimeProperty("Name");
// idProperty = null
// nameProperty = System.String Name
Wie erwartet das properties
Objekt enthält zwei Eigenschaftsdefinition für die Id und Name-Eigenschaft defintions und die nameProperty hält die Eigenschaft Name Definition. Was nicht erwartet wurde, war das idProperty
Objekt null zu sein ...
Kommen aus dem .NET Framework, ich denke, das war von Microsoft Architekten gedacht, aber ich muss sagen, es scheint nicht etwas, was Sie wirklich erwarten würde passieren. Ich glaube, dass sich ähnliche Methoden ähnlich verhalten sollten, aber GetRuntimeProperty scheint nach öffentlichen Eigenschaften zu filtern, bei denen GetRuntimeProperties keine Filter anwendet.
Hat jemand eine vernünftige Erklärung dafür, warum Microsoft entschieden hat, dass diese ähnlichen Methoden unterschiedliche Verhaltensweisen haben sollten? Ein Designfehler?
Danke.
Beachten Sie, dass die Verwendung nur in einer Store-App erforderlich ist. Also, was Sie sehen, ist ein Kompromiss, IInspectable ist nicht gerade eine reiche Schnittstelle. –
Sie haben die neuen Reflektions-APIs komplett bugsiert. Es ist ein Durcheinander auf so viele Arten, dass ich nicht einmal weiß, wo ich anfangen soll. –