Difference between ComponentModel reflection (e.g PropertyDescriptor) and standard reflection (e.g PropertyInfo)?

Question

There is a distinct overlap between what u can do with both of them. Is the ComponentModel reflection stuff just a little friendlier layer on top of System.Reflection?

Answer 1

No - there is more. ComponentModel allows you to do a few DLR-type things, such as runtime-properties. This is how a DataView exposes columns to a grid - they aren't reflection properties - they are runtime properties. The keywords here are ICustomTypeDescriptor and TypeDescriptionProvider.

This model also allows abstraction and indirection. For example, if you are doing a lot of reflection on properties, consider HyperDescriptor - this is a utility I wrote that uses a custom PropertyDescriptor implementation to swap the reflection model for a pre-compiled model, for huge performance boosts.

In terms of usage, there are some other differences; ComponentModel only supports a single instance of any attribute on a member (unlike reflection, where multiple alike attributes are allows). And it is data-centric - so properties exist, as do events (primarily intended for change notification) - but there are no fields nor methods.

It also has good support for i18n - since the DisplayName etc can be customized on the fly.

However, ComponentModel is not (directly) compatible with things like LINQ (MemberExpression in particular) - since this wants to bind to reflection data.

Finally, ComponentModel is highly used in the IDE by things like PropertyGrid (this is how things like the extra properties for tool-tips work), but equally almost all UI data binding happens via ComponentModel (since this allows the binding to support DataTable, classes, and anything else you can think of).