Reflecting on reflection

Published 11 February 04 03:41 PM | despos

I have a sort of love-hate relationship with .NET reflection. Being a form of indirect programming, reflection is not as fast as early-bound code. However, that is a secondary point to me. Avoiding any performance-related gripes, my points about reflection are the following:

  • I love the flexibility that reflection provides
  • I hate the messy code it forces you to write

Reflection-based code is hard to read and maintain. So far I've been able to make use of reflection only to build infrastructural code--not directly application code. Love to see your thoughts about reflection and scenarios in which you're using it and comments you want to share.

Why reflection today? I'm working on a possible implementation of themes in ASP.NET 1.1.

I have a text file representing the skin to apply to all controls of a certain type. The text file lists a group of property/value pairs. For example,

<button>
<property>BackColor</property>
<value>Color.Gainsboro</value>
</button>

where BackColor is the property name and Color.Gainsboro is the corresponding value. Now imagine that you have some runtime code that loops through the controls of a page and applies to each control the skin settings. You can use reflection to set the BackColor property of a Button to a certain color. Sure, it is possible but you need to:

  1. Retrieve the PropertyInfo object for the property
  2. Set the value making sure that you pass in an expression of the proper type.

The second point is the harder I think.

So I discarded reflection and opted for code generation much like you do in a .NET project when you reference a Web service. You import the WSDL and the project generates the proxy file for you. That's what I did and it works. The drawback is that I currently lack tools integrated in VS.NET to automate the process.

There's a better option though and it is just what ASP.NET 2.0 does. In that case, with a significant help from the new compilation model. The idea is generating the code for the theme object at runtime. You look at files in theme directory, parse them in a VB/C# source and compile on the fly. Next, you load the assembly in the app.

It is not for the faint-hearted but it gets the better of both world--early-binding and flexibility.

Haven't started coding yet...

  

 

Comments

# Kathleen Dollard said on February 11, 2004 11:18 AM:

Interesting idea on generating at compile time.

But how will you manage debugging scenarios? Will you be able to do this and maintain correct linkage of exisitng code with the PDB? Will the user have, or need, any debugging of the themes themselves.

I do a significant amount of reflection, and generally minimize the code chaos with wrapping functions. I also use interfaces as much as possible, and if you return to that route, its possible that you can leverage the use of known interfaces to improve performance, although it often doesn't simplify the code.

# Sergio Pereira said on February 11, 2004 12:18 PM:

Just like Kathleen mentioned I also rely heavily on public, well known interfaces to work with reflection. Mostly, my reflection code relates to application extensibility, when I will be calling custom components without prior knowledge of the implementation.

# Chris Anderson said on February 12, 2004 12:20 AM:

Well, not easy, but it does what you want...

Dino is trying to parse "Gainsboro" and set a property "BackColor":

object o = this;
PropertyDescriptor bg = TypeDescriptor.GetProperties(o)["BackColor"];
TypeConverter c = bg.Converter;
object v = c.ConvertFromString("Red");
bg.SetValue(o, v);

This is using System.ComponentModel, basically the same code that the designers and code generators use inside of Visual Studio...

# Andres Aguiar said on February 12, 2004 05:34 AM:

You can also switch to VB.NET when you want to do heavy use of reflection and use late binding.

# TrackBack said on February 12, 2004 06:34 AM:
# TrackBack said on February 12, 2004 06:35 AM:
# Rick Strahl said on February 12, 2004 04:16 PM:

This should work too:

Object.GetType().GetProperty(Property,BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Static | BindingFlags.Instance |
BindingFlags.IgnoreCase).SetValue(Object,Value,null);

I use reflection a lot in internal code. To make stuff like this easier to write I have wrapper methods that are slightly more intuitive. Like wwUtils.SetProperty(object,Property,Value), wwUtils.CallMethod(object,Method,params Parms) all of which reduce the pain significantly. Another thing quite useful is to have routines that are recursive and allow you to specify '.' syntax in the property value so you can drill into lower object members (ie. wwUtils.GetPropertyEx(o,"Company.Address");

Reflection has a bunch of ways to do retrieve. I never spend much time seeing which approaches are the most efficient. GetProperty, PropertyDescriptor, InvokeMember(). Anybody done any perf tests on that?

# olesja said on February 2, 2008 04:31 PM:

<a href= http://index1.thewarhal.com >the cumberland times</a>

Leave a Comment

(required) 
(required) 
(optional)
(required)