Diferencia entre la reflexión de ComponentModel (por ejemplo, PropertyDescriptor) y la reflexión estándar (por ejemplo, PropertyInfo)?

Question

Existe una superposición distintiva entre lo que puede hacer con ambos. ¿El reflejo de ComponentModel es solo una capa más amigable sobre System.Reflection?

Answer 1

No, hay más. ComponentModel le permite hacer algunas cosas de tipo DLR, como propiedades de tiempo de ejecución. Así es como un DataView expone columnas a una grilla, no son propiedades de reflejo, son propiedades de tiempo de ejecución. Las palabras clave aquí son ICustomTypeDescriptor y TypeDescriptionProvider.

Este modelo también permite la abstracción y la indirección. Por ejemplo, si está reflexionando mucho sobre las propiedades, considere HyperDescriptor; esta es una utilidad que escribí y que usa una implementación personalizada de PropertyDescriptor para cambiar el modelo de reflexión por un modelo precompilado, para aumentar el rendimiento.

En términos de uso, existen algunas otras diferencias; ComponentModel solo admite una sola instancia de cualquier atributo en un miembro (a diferencia de la reflexión, donde se permiten múltiples atributos similares). Y está centrado en los datos, por lo que existen propiedades, al igual que los eventos (principalmente destinados a la notificación de cambios), pero no hay campos ni métodos.

También tiene un buen soporte para i18n, ya que el DisplayName etc. se puede personalizar sobre la marcha.

Sin embargo, ComponentModel no es (directamente) compatible con elementos como LINQ (MemberExpression en particular), ya que esto se quiere vincular a los datos de reflexión.

Finalmente, ComponentModel es muy utilizado en el IDE por cosas como PropertyGrid (así es como funcionan las propiedades adicionales para tool-tips), pero casi todos los enlaces de datos de UI se realizan a través de ComponentModel (ya que esto permite admite DataTable, clases y cualquier otra cosa que se te ocurra).