I’ve recently started a project with a few mates to learn
the ins and outs of Dependency Injection, AOP and a number of other pretty crucial patterns of development as we’ve all been using these patterns for a while but have relied totally on third part solutions to do
the magic. We thought it would be interesting to really get into
the details by rolling our own IoC container and hopefully learn a lot on
the way, and you never know, we might even create an excellent framework.
The open source project is called Rapid IoC and is hosted at http://rapidioc.codeplex.com/ One of
the most interesting tasks for me is creating
the dynamic proxy generator for enabling Aspect Orientated Programming (AOP). In this series of articles, I’m going to track each step I take for creating
the dynamic proxy generator and I’ll try my best to explain what everything means - mainly as I’ll be using Reflection.Emit to emit a fair amount of intermediate language code (IL) to create
the proxy types at runtime which can be a little taxing to read. It’s worth noting that building
the proxy is without a doubt going to be slightly painful so I imagine there will be plenty of areas I’ll need to change along
the way. Anyway lets get started… Part 1 - Creating
the Assembly builder, Module builder and caching mechanism Part 1 is going to be a really nice simple start, I’m just going to start by creating
the assembly, module and type caches.
The reason we need to create caches for
the assembly, module and types is simply to save
the overhead of recreating proxy types that have already been generated, this will be one of
the important steps to ensure that
the framework is fast… kind of important as we’re calling
the IoC container ‘Rapid’ – will be a little bit embarrassing if we manage to create
the slowest framework.
The Assembly builder
The assembly builder is what is used to create an assembly at runtime, we’re going to have two overloads, one will be for
the actual use of
the proxy generator,
the other will be mainly for testing purposes as it will also save
the assembly so we can use Reflector to examine
the code that has been created. Here’s
the code: DynamicAssemblyBuilder using System; using System.Reflection; using System.Reflection.Emit; namespace Rapid.DynamicProxy.Assembly { /// <summary> /// Class for creating an assembly builder. /// </summary> internal static class DynamicAssemblyBuilder { #region Create /// <summary> /// Creates an assembly builder. /// </summary> /// <param name="assemblyName">Name of
the assembly.</param> public static AssemblyBuilder Create(string assemblyName) { AssemblyName name = new AssemblyName(assemblyName); AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly( name, AssemblyBuilderAccess.Run); DynamicAssemblyCache.Add(assembly); return assembly; } /// <summary> /// Creates an assembly builder and saves
the assembly to
the passed in location. /// </summary> /// <param name="assemblyName">Name of
the assembly.</param> /// <param name="filePath">The file path.</param> public static AssemblyBuilder Create(string assemblyName, string filePath) { AssemblyName name = new AssemblyName(assemblyName); AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly( name, AssemblyBuilderAccess.RunAndSave, filePath); DynamicAssemblyCache.Add(assembly); return assembly; } #endregion } } So hopefully
the above class is fairly explanatory, an AssemblyName is created using
the passed in string for
the actual name of
the assembly. An AssemblyBuilder is then constructed with
the current AppDomain and depending on
the overload used, it is either just run in
the current context or it is set up ready for saving. It is then added to
the cache. DynamicAssemblyCache using System.Reflection.Emit; using Rapid.DynamicProxy.Exceptions; using Rapid.DynamicProxy.Resources.Exceptions; namespace Rapid.DynamicProxy.Assembly { /// <summary> /// Cache for storing
the dynamic assembly builder. /// </summary> internal static class DynamicAssemblyCache { #region Declarations private static object syncRoot = new object(); internal static AssemblyBuilder Cache = null; #endregion #region Adds a dynamic assembly to
the cache. /// <summary> /// Adds a dynamic assembly builder to
the cache. /// </summary> /// <param name="assemblyBuilder">The assembly builder.</param> public static void Add(AssemblyBuilder assemblyBuilder) { lock (syncRoot) { Cache = assemblyBuilder; } } #endregion #region Gets
the cached assembly /// <summary> /// Gets
the cached assembly builder. /// </summary> /// <returns></returns> public static AssemblyBuilder Get { get { lock (syncRoot) { if (Cache != null) { return Cache; } } throw new RapidDynamicProxyAssertionException(AssertionResources.NoAssemblyInCache); } } #endregion } }
The cache is simply a static property that will store
the AssemblyBuilder (I know it’s a little weird that I’ve made it public, this is for testing purposes, I know that’s a bad excuse but hey…) There are two methods for using
the cache – Add and Get, these just provide thread safe access to
the cache.
The Module Builder
The module builder is required as
the create proxy classes will need to live inside a module within
the assembly. Here’s
the code: DynamicModuleBuilder using System.Reflection.Emit; using Rapid.DynamicProxy.Assembly; namespace Rapid.DynamicProxy.Module { /// <summary> /// Class for creating a module builder. /// </summary> internal static class DynamicModuleBuilder { /// <summary> /// Creates a module builder using
the cached assembly. /// </summary> public static ModuleBuilder Create() { string assemblyName = DynamicAssemblyCache.Get.GetName().Name; ModuleBuilder moduleBuilder = DynamicAssemblyCache.Get.DefineDynamicModule (assemblyName, string.Format("{0}.dll", assemblyName)); DynamicModuleCache.Add(moduleBuilder); return moduleBuilder; } } } As you can see,
the module builder is created on
the assembly that lives in
the DynamicAssemblyCache,
the module is given
the assembly name and also a string representing
the filename if
the assembly is to be saved. It is then added to
the DynamicModuleCache. DynamicModuleCache using System.Reflection.Emit; using Rapid.DynamicProxy.Exceptions; using Rapid.DynamicProxy.Resources.Exceptions; namespace Rapid.DynamicProxy.Module { /// <summary> /// Class for storing
the module builder. /// </summary> internal static class DynamicModuleCache { #region Declarations private static object syncRoot = new object(); internal static ModuleBuilder Cache = null; #endregion #region Add /// <summary> /// Adds a dynamic module builder to
the cache. /// </summary> /// <param name="moduleBuilder">The module builder.</param> public static void Add(ModuleBuilder moduleBuilder) { lock (syncRoot) { Cache = moduleBuilder; } } #endregion #region Get /// <summary> /// Gets
the cached module builder. /// </summary> /// <returns></returns> public static ModuleBuilder Get { get { lock (syncRoot) { if (Cache != null) { return Cache; } } throw new RapidDynamicProxyAssertionException(AssertionResources.NoModuleInCache); } } #endregion } }
The DynamicModuleCache is very similar to
the assembly cache, it is simply a statically stored module with thread safe Add and Get methods.
The DynamicTypeCache To end off this post, I’m going to create
the cache for storing
the generated proxy classes. I’ve spent a fair amount of time thinking about
the type of collection I should use to store
the types and have finally decided that for
the time being I’m going to use a generic dictionary. This may change when I can actually performance test
the proxy generator but
the time being I think it makes good sense in theory, mainly as it pretty much maintains it’s performance with varying numbers of items – almost constant (0)1. Plus I won’t ever need to loop through
the items which is not
the dictionaries strong point. Here’s
the code as it currently stands: DynamicTypeCache using System; using System.Collections.Generic; using System.Security.Cryptography; using System.Text; namespace Rapid.DynamicProxy.Types { /// <summary> /// Cache for storing proxy types. /// </summary> internal static class DynamicTypeCache { #region Declarations static object syncRoot = new object(); public static Dictionary<string, Type> Cache = new Dictionary<string, Type>(); #endregion /// <summary> /// Adds a proxy to
the type cache. /// </summary> /// <param name="type">The type.</param> /// <param name="proxy">The proxy.</param> public static void AddProxyForType(Type type, Type proxy) { lock (syncRoot) { Cache.Add(GetHashCode(type.AssemblyQualifiedName), proxy); } } /// <summary> /// Tries
the type of
the get proxy for. /// </summary> /// <param name="type">The type.</param> /// <returns></returns> public static Type TryGetProxyForType(Type type) { lock (syncRoot) { Type proxyType; Cache.TryGetValue(GetHashCode(type.AssemblyQualifiedName), out proxyType); return proxyType; } } #region Private Methods private static string GetHashCode(string fullName) { SHA1CryptoServiceProvider provider = new SHA1CryptoServiceProvider(); Byte[] buffer = Encoding.UTF8.GetBytes(fullName); Byte[] hash = provider.ComputeHash(buffer, 0, buffer.Length); return Convert.ToBase64String(hash); } #endregion } } As you can see, there are two public methods, one for adding to
the cache and one for getting from
the cache. Hopefully they should be clear enough,
the Get is a TryGet as I do not want
the dictionary to throw an exception if a proxy doesn’t exist within
the cache. Other than that I’ve decided to create a key using
the SHA1CryptoServiceProvider, this may change but my initial though is
the SHA1 algorithm is pretty fast to put together using
the provider and it is also very unlikely to have any hashing collisions. (there are some maths behind how unlikely this is – here’s
the wiki if you’re interested http://en.wikipedia.org/wiki/SHA_hash_functions) Anyway, that’s
the end of part 1 – although I haven’t started any of
the fun stuff (by fun I mean hairpulling, teeth grating Relfection.Emit style fun), I’ve got
the basis of
the DynamicProxy in place so all we have to worry about now is creating
the types, interceptor classes, method invocation information classes and finally a really nice fluent interface that will abstract all of
the hard-core craziness away and leave us with a lightning fast, easy to use AOP framework. Hope you find
the series interesting. All of
the source code can be viewed and/or downloaded at our codeplex site - http://rapidioc.codeplex.com/ Kind Regards, Sean.
