Coding Adventure

If you are building an application that has a lot of modules and those modules can be plugged in dynamically then you will probably want to use inversion of control (IoC).

What can inversion of control do for you?

• help you deal with the configuration of all the modules
• a one “single point change” so you wont have to hunt down every other place where things could go wrong
• help with transparency as you just have to use a module and not worry how it is implemented
• provide a nice way to have strong contracts (due to interfaces)
• finally, the application can change it’s own behavior when it believes it is necessary at runtime

If you want to learn more I would recommend reading the the famous article written by Martin Fowler.

Sometimes we have to implement code that is only meant to work for us as developers and not the our clients. That is when conditional debug comes to play. Using conditional debug it is possible to only allow some functions to be called only if the project is running in debug mode.

I found it useful on the following scenarios:

• Impersonation – change my context to a specific user contex.
• Tracing/Profiling
• Testing

[Conditional("DEBUG")]

  public void OnlyRunIfUnderDebug(string person)
       {
           //replace context with person's arguments context
           //profiling
           //testing
           //etc
       }

I am currently writing a mock application and this mock application requires that some modules can be plugged in dynamically.

This resembled a inversion of control (IoC) problem. For those of you unfamiliar with inversion of control containers, here is a quick elevator pitch:

• easy best practice unit testing
• component reuse
• configuration given to components
• clean & declarative architecture
• maintainability
• adaptability
• transparency

Grabbed from the http://www.picocontainer.org/ website and based on the famous article written by Martin Fowler.

I personally like StructureMap for my IoC container needs. I like it because when I first tried it, I was able to get it to work in almost no time and there is a lot of relevant developer documentation available.

For the mock project, once I hooked up the bootstrapper to get StructureMap to work with nice lamda expressions, I published my project to GoDaddy to test it out – I ran into a problem. I received a nasty security exception due to GoDaddy’s security permissions. I looked online and the same problem was described by Jon Erickson who posted the problem at Stack Overflow.

Instead of trying to engineer a solution to make StructureMap work with GoDaddy, I decided to try another IoC container as many of them have become very popular in the last few years.

Scott Hanselman has compiled a nice list and Chris Brandsma has some neat examples. Instead of going with my first instincts (Ninject, Autofac or Windsor), I decided to test out Unity as I wanted to try something new. What really sold me were:

1. it is part of the Microsoft patterns & practices;
2. a neat screen cast by David Hayden showed how easy it is to use; and
3. the fact that Brad Wilson was a contributor (Brad is currently working on another project I like, xUnit.net ).

Basically, with Unity, I ended up writing (simplified version) :

IUnityContainer container = new UnityContainer();

container.RegisterType<IRiskRepository, RiskRepository>();

string conn = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;

container.Configure<InjectedMembers>().ConfigureInjectionFor<RiskRepository>(new InjectionConstructor(conn));

UnityControllerFactory factory = new UnityControllerFactory(container);

ControllerBuilder.Current.SetControllerFactory(factory);

Unity turned out to work very well. I was able to save a lot of lines of code and it is greatly improving the testability of the dynamic modules I am using on the mock project architecture. Also, it was easy to set up and it works with GoDaddy under medium trust.