Adventures in .NET Software Craftsmanship!

Don’t ask why! but I had to code this workaround to plug into some legacy code efficiently and I decided to make the most of the opportunity.

I kept constantly hitting a road block when interacting with a third party assembly that talked to some legacy web services. In a nutshell, everything worked fine as long as I only called one method per instance of the class, needless to say this was terribly annoying so I decided to do something about it and learn some of the basics of Castle.DynamicProxy to build myself a generic proxy object that lets you implement a per method call lifecycle for an object. Now this is not intended to be a Castle.DynamicProxy tutorial, but I will try to introduce some of the basics that I learned while coding my solution.

What is Castle.DynamicProxy?

Is an OSS project that provides you with the functionality to build dynamic proxy instances to inject functionality that addresses common application concerns. In other words, you could build proxies to address security, logging, monitoring and many other repetitive tasks that needs to be coded into any system. It is used by a ton of very successful open source projects such as AutoMapper, NHibernate and Moq to name a few. It is extremely easy to use as most of its functionality is exposed by a single class the Castle.DynamicProxy.ProxyGenerator which is usually managed as a single instance (singleton) within your application.

Enough! Lets talk code. The following snippet shows a simple IService interface and its implementation. The implementation merely writes some information into the console that should gives us a visual clue (a guid) to easily identity the instance of the object that is servicing the request.

When we use the functionality of the class, as illustrated in the following snippet, we see the same guid displayed every time the DoSomething method is called. Now, if you recalled my objective is to implement a way to create a new instance of the object per method call. In other words, I want to see a different guid for a every single method call to an instance of a proxied IService implementation.

The obvious solution is to build a proxy that would allow you to create a new instance to service the request every time a method is called. We could code a very simple proxy specific for the IService interface that will do the job in not many lines of code, but there is no fun in that. Plus, it would restrict the solution to be specific to the IService and its implementations. By using Castle.DynamicProxy we can implement a generic solution that would allow us to inject this functionality into any object regardless of its contract by using a Proxy and an Interceptor. The following is such interceptor.

Now, if you follow the code above the interceptor has a single constructor parameter that is a Func<T> used to build an instance of the class you are going to proxy. In its intercept method, which as its name states just intercepts the method calls, there is functionality to build an instance of the class and service the request through Castle’s invocation API. You might want to add additional logic to make the implementation more robust such as validating that the call is for a method not a property but for demo purposes I kept it simple. Now the following code is a sample usage that produces the desired outcome by using this interceptor on the IService interface and its implementation object.

From the above snippet the only line that is somewhat confusing is the one where we are instantiating the service, but once you grasp what is doing is actually very simple. As the method name implies you are creating a proxy object of type IService with a target, which in our scenario is never going to be used, this allows the interceptor that is targeting the proxy to do the heavy lifting and switch the target of the invocation as needed.

Hopefully, this post illustrates some of the very basic yet powerful things that can be done with Castle.DynamicProxy and how it can help you get out of a bind using non-traditional coding techniques.

Lately I have been working with an existing custom .NET Library designed to register and execute tasks triggered by events, sort of like a local Event Bus. The Library was built in house and is used successfully in many applications but it lacks integration with Dependency Injection or Common Service Locator which makes it hard to implement in a solution where separation of concerns are enforced strictly.

To highlight the issue, look at the following snippet, it is a sample of the exposed API for registering tasks associated to an event.

At first glance, there is nothing wrong with the previous code but if you look more carefully you will notice that we are passing a concrete instance of a type. Now, my preference would be to pass just a type and have the event task library instantiate the type and its dependencies using some form of service location, but modifying the event task library is not an option for us at this time. One possible solution is to simply use Service Location when we are registering our associated events, as you can see in the following snippet.

RegisterFor<OnSomeEvent>(new SomeTask(ObjectFactory.GetInstance<IRepository>()));
// Or Even Less Code.
RegisterFor<OnSomeEvent>(ObjectFactory.GetInstance<SomeTask>());

Luckily in the current project all tasks are registered during startup so there isn’t much wrong with muddying the registration code with service location. But, at this point we have unknowingly created another issue, since the execution of the registration code happens once during system startup the tasks and its dependencies will be unique throughout the execution of the application. This is a huge problem for us as our current implementation of the IRepository behaves differently depending on context information provided during instantiation, see snippet.

One possible solution, is to modify the way we write our implementation of ITask to allow for lazy instantiation of its dependencies but still take of advantage of Dependency Injection an Inversion Of Control. The following snippet highlights the solution the key is to inject a Func<IRepository> not an IRepository, that way the consumer is actually the one who will be instantiating the dependency on demand.

I have made my slides and code available from my presentation on MVC Extensibility at the MVC Conference. Before I give out the details, I would like to congratulate the organizers of the event for their great work on making this amazing event happen. In particular, I would like to extend a personal thanks to Eric Hexter, and Javier Lozano. Thanks again guys, for giving me the opportunity to speak on such an amazing digital venue.

I am excited to announce that I will be participating as a presenter at MVCConf. MVC Conference (MVCConf) is a free virtual conference focused on one thing only, writing awesome application on top of the ASP.NET MVC applications, for more information go to http://www.mvcconf.com.

I will be doing a presentation on MVC Extensiblity focused on plugging functionality onto your MVC application to enforce separation of concerns therefore enhancing testability. The following are the preliminary details:

MVC2 Extensibility

Learn the basic extensibility points of the ASP.NET MVC Framework by refactoring an existing code base and making changes that will make your application less fragile and easier to test. The main focus will be how to leverage dependency injection, routes, action filters, model binders, etc. to build a better all-around application.

A while back I wrote about testing Controller Actions that rely on MVC2’s new Model Validation. I had been using the technique described in the post for a while on most of my MVC2 applications without running into any significant issue until I tried to combine validators on a single property of my Model. The following are the modified testing scenarios that would not work with the code I provided in my originally post. Apparently, the code I wrote originally does not target all validators that are applied through Metadata.

This time around I feel like I did better research to find a suitable solution by looking at the ASP.NET MVC 2 source code and its tests. In my original post, I had overlooked a couple of reusable tools already in place in the ASP.NET MVC source code that would have made my work a whole lot easier like the ModelMetadataProviders, and DataAnnotationsModelValidatorProvider. Of course, there is always room for improvement, but the following is the refactored ControllerExtensions class that allows for all the previous tests to go green.

The Author

Currently a Developer Extraordinaire at InfernoRed Technology based out of Northern Virginia. I have been architecting and building software solutions using Microsoft technology for the past 14 years. I was awarded a Microsoft MVP award for C# in 2007,2008 and 2010 and currently an active participant of the Microsoft MVP reConnect program. I am originally from the Dominican Republic, and the proud father of two beautiful daughters that make my life special. You can track me down on twitter (@hernandezrobert) and on this blog at http://www.overridethis.com.