Wir sind in einem Projekt in ein sehr kniffliges Szenario geraten. Wir haben viel Reflexion in unserem Projekt verwendet.
Wir haben ..
- Validierungsframework basierend auf Attributen und Reflektion
- Erweiterungsmethoden, die eine DataRow mithilfe von Attributen und Reflexion in ein Entitätsobjekt umwandeln und umgekehrt. Dasselbe haben wir für DataTable und EntityCollections getan.
- IComparer-Schnittstelle, die in der generischen EntityComparer-Klasse implementiert ist, die Reflection verwendet, um zwei Entity OBjects zu vergleichen.
Wie in den obigen Szenarien haben wir Reflections an vielen anderen Stellen in unserer Anwendung verwendet. Nach dem Verwenden der Reflektion haben wir festgestellt, dass die Anwendung mehr Verarbeitungszyklen mit Reflektion benötigt.
Inwieweit sollten wir Reflection in unseremProjekt? In welchen Bereichen eines Projekts wirkt sich die Reflexion in Bezug auf die Bearbeitung am negativsten aus? Wo Reflexion keinen Einfluss auf die Leistung hat? Gibt es Richtlinien zur Verwendung von Reflection?
Antworten:
4 für die Antwort № 1Reflexion ist stark, hat aber Nachteile. Versuchen Sie im Allgemeinen, ohne Code zu arbeiten - dies ist jedoch äußerst nützlich für "Framework" -Bibliotheken, in denen Sie nur wenig oder nur begrenztes Wissen über die tatsächlichen Objekte haben. beispielsweise:
- ORM / DAL-Tools (Laden / Speichern beliebiger Daten)
- Datenbindung
- Serialisierung
Es gibt Leistungseinbußen mit Ad-hoc-Überlegungen, aber wenn Sie es tun werden viele (innerhalb Ihrer Bibliothek und in einer engen Schleife) können Sie dagegen vorgehen:
- durch die Nutzung
Delegate.CreateDelegate(Als ein getippt delegieren; nicht verwendenDynamicInvoke) - indem Sie dynamische IL schreiben
- durch die Nutzung
Expressionin .NET 3.5
Und natürlich sollte jeder solche Code zwischengespeichert und wiederverwendet werden (Sie möchten nicht bei jedem Aufruf kompilieren und ausführen; nur der erste - der Rest sollte nur ausgeführt werden).
Oder es gibt Bibliotheken, die dies abstrahieren; beispielsweise, HyperPropertyDescriptor Wraps benutzerdefinierte IL (für den Zugriff auf Mitglieder) in die vertraute PropertyDescriptor API - macht es sehr schnell, aber schmerzlos. In Ihrer Frage werden Datentabellen und Entitäten genannt. das klingt ein Menge mögen Diese vorherige Frage, wo ich einige Metriken mit HyperDescriptor gemacht habe, mit Zusammenfassung (in Millisekunden):
Vanilla 27179
Hyper 6997
Also mein "take":
- in dem Anwendung; sehr wenig - als letztes Mittel überhaupt
- in deinem gemeinsame Bibliothek / Bibliotheken; Gegebenenfalls (bitte beachten Sie, dass Schnittstellen usw. nach Möglichkeit vorzuziehen sind)
1 für die Antwort № 2
Wenn der Schuh passt, dann trage ihn ... Wenn es das vorliegende Problem löst und keine übermäßige Verarbeitung verursacht, wie durch eine Art von Test (vorzugsweise ein Profiler), dann mach dir keine Sorgen. Es gibt viele Probleme, die sich durch Reflexion leicht lösen lassen.
Die einzige Richtlinie, die ich in Bezug auf die Entscheidung, keine Reflexion zu verwenden, habe, besteht darin, sie zu verwenden, um auf Eigenschaften zuzugreifen, auf die Sie normalerweise keinen Zugriff haben (dh auf private Eigenschaften in der Klasse einer anderen Person).
1 für die Antwort № 3
Ihre nicht-funktionale Anforderung / QoS solltebestimmen, ob es angebracht ist, Reflexion zu verwenden, und wie bei meinem Kommentar, Test, Test, Test (Einheit, Leistungstest usw.). Wenn Ihr Kunde mit der Leistung zufrieden ist, kann und kann er bei richtiger Anwendung einen gewissen Produktivitätsgewinn erzielen.
Ich persönlich werde mich dafür entscheiden, keine Reflexion zu verwenden, wann immer ich kann.
1 für die Antwort № 4
Reflexion kann echte Vorteile bringenErweiterbarkeit und Flexibilität. Bei der Verwendung von Reflection ist ein Leistungsverlust zu verzeichnen, der Sie jedoch nicht sofort abschreckt, insbesondere wenn Sie dadurch mehr Vorteile erzielen. Versuchen Sie, Reflection sparsam zu verwenden, aber gehen Sie nicht davon aus, dass die Verwendung bei Bedarf erheblich schadet. Dieser Artikel ist gut zu diesem Thema: http://www.west-wind.com/weblog/posts/351.aspx
1 für die Antwort № 5
Mein Rat ist, immer zu versuchen, ein Objekt zu findenorientierte Lösung zuerst, anstatt bei der ersten Gelegenheit auf Reflexion zurückzugreifen. Es mag einfacher sein, etwas mit Reflektion zu erreichen, aber mit einer OO-Lösung wird der Code im Allgemeinen besser organisiert, und Sie werden den Overhead der Reflektion los.
In meinen Jahren als Entwickler habe ich nur verwendetÜberlegungen zweimal ... Die erste bestand darin, auf eine private Variable zuzugreifen, um den Upload-Fortschritt einer Web-Anfrage zu erhalten. Die zweite bestand darin, beim Lesen von einem Datenleser dynamisch Objektinstanzen zu erstellen, die ich später gerne durch eine generische Lösung ersetzte.