views:

2039

answers:

2

Questions about Making reflection fly and exploring delegates...

If I need to create delegates Func<T, TResult> to methods on dynamically loaded types I could potentially use (1) Delegate.CreateDelegate (2) DynamicMethod (3) Expression trees.

Lets say the set of dynamically loaded types/methods are reflected once at application startup via config and used throughout the lifetime of the app (start-up performance is not an issue and neither is memory), the delegates are cached and dispatched to in a strongly-typed way. These delegates are hot paths accessed concurrently.

Which dynamic binding method would you prefer and why?

+3  A: 

If they're actually existing methods which you have a MethodInfo for, and they have the right signatures, then I'd say Delegate.CreateDelegate is the right way to go - it does exactly what you want, with no fuss. I'd use DynamicMethod or expression trees if I needed to build a delegate to execute some logic which wasn't already captured in a method.

Expression trees are (IMO, and I haven't used DynamicMethod in anger) slightly easier to use than DynamicMethod, but they're more restricted - basically they can only represent a single expression (which could call another method, of course). DynamicMethod gives you lots of flexibility, but you need to understand IL reasonably well.

Does that help?

Jon Skeet
Dynamic methods rock when you get them to work. Getting them to work though often involves lots of starring at IL, frustration and bouts with peverify. But they produce awesome results.
JaredPar
It confirms my thoughts as well. Googling around about delegates it seems like quite a few folks are using DynamicMethod to solve this problem. I have an app that makes heavy use of Delegate.CreateDelegate in the way I described.
jsw
+1  A: 

Via Ayende's blog I got this interesting link which shows off the kind of things you can do with Dynamic Methods. As an example it is quite understandable:
Accelerating Enum-Based Dictionaries with Generic EnumComparer

flq