Разница между отражением ComponentModel (например, PropertyDescriptor) и стандартным отражением (например, PropertyInfo)?

Существует явное перекрытие между тем, что u может сделать с ними обоими. Является ли материал отражения ComponentModel просто немного более дружелюбным слоем поверх системы.Отражение?

1 26
c# reflection

1 ответ:

Нет - есть еще. ComponentModel позволяет вам делать некоторые вещи типа DLR, такие как runtime-properties. Именно так DataView предоставляет столбцы сетке - это не свойства отражения, а свойства среды выполнения. Ключевые слова здесь - ICustomTypeDescriptor и TypeDescriptionProvider.

Эта модель также допускает абстракцию и косвенность. Например, если вы много размышляете о свойствах, рассмотрим HyperDescriptor - это утилита, которую я написал, которая использует пользовательскую реализацию PropertyDescriptor, чтобы замените модель отражения на предварительно скомпилированную модель, чтобы увеличить производительность.

С точки зрения использования, есть и некоторые другие различия; ComponentModel поддерживает только один экземпляр любого атрибута на члене (в отличие от отражения, где допускается несколько одинаковых атрибутов). И он ориентирован на данные-так что свойства существуют, как и события (в первую очередь предназначенные для уведомления об изменениях) - но нет ни полей, ни методов.

Он также имеет хорошую поддержку для i18n-так как DisplayName etc можно подгонять на лету.

Однако ComponentModel не совместим (напрямую) с такими вещами, как LINQ (в частности, MemberExpression), поскольку он хочет привязаться к данным отражения.

Наконец, ComponentModel широко используется в IDE такими вещами, как PropertyGrid (именно так работают дополнительные свойства для подсказок), но в равной степени почти все привязки данных пользовательского интерфейса происходят через ComponentModel (поскольку это позволяет привязке поддерживать DataTable, классы и все остальное еще можно придумать).

30