Differenza tra riflessione ComponentModel (ad esempio PropertyDescriptor) e riflessione standard (ad esempio PropertyInfo)?

Question

C'è una chiara sovrapposizione tra ciò che si può fare con entrambi. Il materiale di riflessione ComponentModel è solo un piccolo strato più amichevole in cima a System.Reflection?

Answer 1

No - c'è di più. ComponentModel ti permette di fare alcune cose tipo DLR, come le proprietà di runtime. Ecco come un DataView espone le colonne a una griglia: non sono proprietà di riflessione, sono proprietà di esecuzione. Le parole chiave qui sono ICustomTypeDescriptor e TypeDescriptionProvider.

Questo modello consente anche l'astrazione e la direzione indiretta. Ad esempio, se si sta facendo molta riflessione sulle proprietà, si consideri HyperDescriptor - questa è un'utilità che ho scritto che utilizza un'implementazione personalizzata PropertyDescriptor per scambiare il modello di riflessione per un modello precompilato, per enormi incrementi di prestazioni.

In termini di utilizzo, ci sono alcune altre differenze; ComponentModel supporta solo una singola istanza di qualsiasi attributo su un membro (diversamente dalla riflessione, dove sono consentiti più attributi simili). Ed è incentrato sui dati - così esistono le proprietà, così come gli eventi (destinati principalmente alla notifica di modifiche) - ma non ci sono campi né metodi.

Ha anche un buon supporto per i18n - dal momento che DisplayName ecc può essere personalizzato al volo.

Tuttavia, ComponentModel non è (direttamente) compatibile con cose come LINQ (MemberExpression in particolare) - poiché questo vuole legarsi ai dati di riflessione.

Infine, ComponentModel è molto utilizzato nell'IDE per cose come PropertyGrid (questo è il modo in cui funzionano le proprietà extra per i tool-tips), ma allo stesso modo quasi tutti i dati UI vincolanti avvengono tramite ComponentModel (poiché ciò consente al binding di supporta DataTable, classi e qualsiasi altra cosa tu possa pensare).