Il y a un chevauchement distinct entre ce que vous pouvez faire avec les deux. Le reflet ComponentModel est-il simplement un calque plus convivial sur System.Reflection?Différence entre la réflexion ComponentModel (par exemple PropertyDescriptor) et la réflexion standard (par exemple PropertyInfo)?
Non - il y a plus. ComponentModel vous permet de faire quelques choses de type DLR, telles que les propriétés d'exécution. C'est ainsi qu'un DataView expose des colonnes à une grille - ce ne sont pas des propriétés de réflexion - ce sont des propriétés d'exécution. Les mots-clés ici sont ICustomTypeDescriptor et TypeDescriptionProvider.
Ce modèle permet également l'abstraction et l'indirection. Par exemple, si vous faites beaucoup de réflexion sur les propriétés, considérez HyperDescriptor - c'est un utilitaire que j'ai écrit qui utilise une implémentation personnalisée PropertyDescriptor pour permuter le modèle de réflexion pour un modèle pré-compilé, pour des gains de performances énormes.
En termes d'utilisation, il existe d'autres différences; ComponentModel ne prend en charge qu'une seule instance de n'importe quel attribut sur un membre (contrairement à la réflexion, où plusieurs attributs similaires sont autorisés). Et il est centré sur les données - donc les propriétés existent, tout comme les événements (principalement destinés à la notification de changement) - mais il n'y a pas de champs ni de méthodes.
Il a également un bon support pour i18n - puisque le DisplayName etc. peut être personnalisé à la volée. Cependant, ComponentModel n'est pas (directement) compatible avec des choses comme LINQ (MemberExpression en particulier) - puisque cela veut se lier aux données de réflexion. Enfin, ComponentModel est très utilisé dans l'EDI par des choses comme PropertyGrid (c'est comme ça que fonctionnent les propriétés supplémentaires des tool-tips), mais presque toutes les liaisons de données UI se font via ComponentModel (puisque cela permet la liaison à soutenir DataTable, les classes, et tout ce que vous pouvez penser).
Je sais que c'est plus ancien que les collines, mais pourriez-vous expliquer certaines choses que vous pouvez et ne pouvez pas faire dans LINQ si vous utilisez System.ComponentModel pour la réflexion? – wootscootinboogie
@woot c'est une réponse courte: LINQ ne se soucie pas de ComponentModel –