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?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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
ICustomTypeDescriptorandTypeDescriptionProvider.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
PropertyDescriptorimplementation 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).