Upto What extent Reflection should be used ?

Question

Hi,

We've got into a very tricky scenario in a project. We have used lot of reflection in our project.

We have ..

• Validation Framework driven by Attributes and Reflection
• Extension methods that transaforms a DataRow to an Entity Object using Attributes and Reflection and vice versa. The same thing we have done for DataTable and EntityCollections.
• IComparer interface implemented on generic EntityComparer class that uses reflection to compare two Entity OBjects.

Like above scenarios we have used Reflections at many other parts in our appication. After using the reflection we have noticed that the application is taking more processing cycles with reflection.

Upto what extent we should use Reflection in our project ? What are the areas of a project that are most adversely affected by reflection in terms of processing ? Where reflection will not make any performance impact ? Are there any guidelines on using Reflection ?

Answer 1

If the shoe fits, then wear it... If it solves the problem at hand, and doesn't cause excess processing as measured by some sort of testing (a profiler, preferably), then don't worry about it. There are plenty of problems that are easily solved with reflection.

The only guideline I have with regards to deciding not to use reflection is using it to get at properties you wouldn't normally have access to (ie. private properties in someone else's class).

Answer 2

Your non-functional requirement / QoS should dictate whether or not it is appropriate to use reflection and as with my comment, test, test, test (unit, performance test, etc.). If your client is happy with the performance, I'd say go for it. It can and does give a certain productivity gain when used correctly.

Personally, I will opt to not use reflection whenever I can.

Answer 3

Reflection can provide real benefits for extensibility and flexibility.There is a performance hit when using reflection but that shouldn't put you off instantly especially if it gives you more benefits. Try to use reflection sparingly but don't assume it will hurt much to use when you need to. This article is good on this subject: http://www.west-wind.com/weblog/posts/351.aspx

Answer 4

My advice is to always try to find an object oriented solution first rather than resorting to reflection at the first opporunity. It may be easier to accomplish something with reflection, but the code generally gets more organised with an OO solution, and you get rid of the overhead of reflection.

Over my years as developer I have only used reflection twice... The first was to get access to some private variable to get the upload progress of a web request. The second was to dynamically create object instances when reading from a data reader, which I later was glad to replace with a generic solution.

Answer 5

Reflection is powerful, but has drawbacks. In general, try to code without it - but it is hugely useful for "framework" libraries, where you have little/limited knowledge what the actual objects will be; for example:

• ORM / DAL tools (loading/saving arbitrary data)
• data-binding
• serialization

There are performance penalties with ad-hoc reflection, but if you are going to do it lots (within your library, and in a tight loop) you can mitigate against this:

• by using Delegate.CreateDelegate (as a typed delegate; don't use DynamicInvoke)
• by writing dynamic IL
• by using Expression in .NET 3.5

And of course, any such code should be cached and re-used (you don't want to compile+execute for every call; just the first - the rest should just execute).

Or there are libraries that abstract this; for example, HyperPropertyDescriptor wraps custom IL (for member access) in the familiar PropertyDescriptor API - making it very fast but painless. Your question mentions data-tables and entities; which sounds a lot like this previous question, where I did some metrics using HyperDescriptor, with summary (in milliseconds):

Vanilla 27179
Hyper   6997

So my "take":

• in the application; very little - as a last resort, generally
• in your common library/libraries; where appropriate (noting that interfaces etc are preferable where possible)