In .NET 3.5, I’m going to be working with System.Reflection to use AOP (probably in the context of Castle’s Windsor Interceptors) to do things like define which security actions need to be performed at the method level, etc. I have heard that some parts of Reflection are slow (I’ve read the MSDN article around it), and would like to cache these parts (when I get closer to production code, at any rate). I would like to validate my approach:
- cache key is {type} + {case sensitive method name} + {list of parameter types}
- cache key objects can be compared via an Equals operation
- cache payload is a {MethodInfo} + {list of custom-attributes defined on the method}
- cache is injected to my interceptors via constructor injection
- cache can be maintained for a long time (based on the assumption that I’m not going to be writing self-modifying code 😉 )
Update:
I’m not intending to call methods via Reflection something I’m writing myself; just (at the moment) look up attributes on the ones I want to inject functionality into, where the attributes define the behaviour to inject. My interceptors at the moment will be using Castle’s Windsor IInterceptor mechanism until I notice a reason to change it.
Explicitly calling a MethodInfo is indeed slow – but you can make it much, much faster if you convert it into a delegate. See this blog post for example. That doesn’t help in terms of finding methods etc of course, but if you’re going to call the method repeatedly it’s worth bearing in mind.
The cache key sounds easy enough to build – types and strings compare nice and easily. Values are always relatively simple 🙂
Once built, is the cache going to be read-only? Can you separate out the phases so that you can guarantee it won’t be read before being fully built? If so, you should be able to get away without any explicit locking – basically a dictionary from your custom key type to your custom value type.