Jusqu'à quel point la réflexion doit-elle être utilisée ?

Question

Nous nous trouvons dans un scénario très délicat dans un projet. Nous avons utilisé beaucoup de réflexion dans notre projet.

Nous avons

• Cadre de validation basé sur les attributs et la réflexion
• Méthodes d'extension qui transforment un DataRow en un Entity Object en utilisant des attributs et Reflection et vice versa. Nous avons fait la même chose pour les DataTable et les EntityCollections.
• Interface IComparer mise en œuvre sur la classe générique EntityComparer qui utilise la réflexion pour comparer deux objets d'entité.

Comme les scénarios ci-dessus, nous avons utilisé les réflexions à plusieurs autres endroits de notre application. Après avoir utilisé la réflexion, nous avons remarqué que l'application prend plus de cycles de traitement avec la réflexion.

Jusqu'à quel point devons-nous utiliser la réflexion dans notre projet ? Quels sont les domaines d'un projet qui sont les plus affectés par la réflexion en termes de traitement ? Où la réflexion n'aura pas d'impact sur les performances ? Existe-t-il des directives sur l'utilisation de Reflection ?

Answer 1

La réflexion est puissante, mais elle a des inconvénients. En général, essayez de coder sans lui, mais il est extrêmement utile pour les bibliothèques de type "framework", où vous savez peu ou pas du tout quels seront les objets réels, par exemple :

• Outils ORM / DAL (chargement/sauvegarde de données arbitraires)
• liaison de données
• sérialisation

Il y a des pénalités de performance avec la réflexion ad hoc, mais si vous allez le faire lots (au sein de votre bibliothèque, et dans une boucle fermée), vous pouvez vous prémunir contre ce problème :

• en utilisant Delegate.CreateDelegate (en tant que dactylographié délégué ; n'utilisez pas DynamicInvoke )
• en écrivant des VA dynamiques
• en utilisant Expression dans .NET 3.5

Et bien sûr, tout code de ce type doit être mis en cache et réutilisé (vous ne voulez pas compiler + exécuter pour chaque appel ; seulement le premier - le reste doit simplement être exécuté).

Ou bien il existe des bibliothèques qui font abstraction de cela ; par exemple, HyperPropertyDescriptor enveloppe l'IL personnalisé (pour l'accès des membres) dans le familier PropertyDescriptor API - ce qui rend le processus très rapide mais sans douleur. Votre question mentionne les tables de données et les entités, ce qui ressemble à une approche de la gestion des données. lot comme cette question précédente où j'ai fait quelques mesures en utilisant HyperDescriptor, avec un résumé (en millisecondes) :

Vanilla 27179
Hyper   6997

Donc ma "prise" :

• dans le application ; très peu - en dernier recours, généralement
• dans votre bibliothèque commune/bibliothèques ; le cas échéant (en notant que les interfaces, etc. sont préférables lorsque cela est possible).

Answer 2

Si la chaussure vous va, portez-la... Si cela résout le problème en question et ne provoque pas de traitement excessif tel que mesuré par une sorte de test (un profileur, de préférence), alors ne vous en faites pas. Il y a beaucoup de problèmes qui sont facilement résolus par la réflexion.

La seule ligne directrice que j'ai en ce qui concerne la décision de ne pas utiliser la réflexion est de l'utiliser pour obtenir des propriétés auxquelles vous n'auriez normalement pas accès (c'est-à-dire des propriétés privées dans la classe de quelqu'un d'autre).

Answer 3

Votre exigence non fonctionnelle / QoS devrait dicter s'il est approprié ou non d'utiliser la réflexion et comme pour mon commentaire, testez, testez, testez (unité, test de performance, etc.). Si votre client est satisfait des performances, je dirais qu'il faut le faire. Elle peut et donne un certain gain de productivité lorsqu'elle est utilisée correctement.

Personnellement, je choisirai de ne pas utiliser la réflexion chaque fois que je le pourrai.

Answer 4

La réflexion peut offrir de réels avantages en termes d'extensibilité et de flexibilité. L'utilisation de la réflexion a un impact sur les performances, mais cela ne doit pas vous décourager immédiatement, surtout si elle vous apporte d'autres avantages. Essayez d'utiliser la réflexion avec parcimonie, mais ne supposez pas qu'il sera difficile de l'utiliser lorsque vous en aurez besoin. Cet article est très intéressant à ce sujet : http://www.west-wind.com/weblog/posts/351.aspx

Answer 5

Mon conseil est de toujours essayer de trouver une solution orientée objet en premier lieu plutôt que de recourir à la réflexion à la première occasion. Il peut être plus facile d'accomplir quelque chose avec la réflexion, mais le code est généralement mieux organisé avec une solution orientée objet, et vous vous débarrassez de la surcharge de la réflexion.

Au cours de mes années en tant que développeur, je n'ai utilisé la réflexion que deux fois... La première fois, c'était pour accéder à une variable privée afin d'obtenir la progression du téléchargement d'une requête web. La seconde était pour créer dynamiquement des instances d'objets lors de la lecture d'un lecteur de données, que j'ai ensuite été heureux de remplacer par une solution générique.