Friday, 29 May 2009

Avoiding static references to an IoC container

It seems quite common for applications to employ a static class to encapsulate the Inversion of Control container. A simple example of such a class might be:

public static class IoC
{
    private static IWindsorContainer _container = new WindsorContainer();

    public static T Resolve<T>()
    {
        return _container.Resolve<T>();
    }
}

While the normal practise would be to inject dependencies through the constructor, there are times where you may need to pass extra arguments as part of the Resolve() method. You might end up with a method such as this:

    public class SomeClass : ISomeClass
    {
        public SomeClass()
        { }

        public void SomeMethod(string name)
        {
            if (name == "david")
            {
                var class1 = IoC.Resolve<IClass1>();
            }
            else
            {
                var class2 = IoC.Resolve<IClass2>();
            }
        }
    }

This works, but because of the tight coupling to the IoC class, it isn’t ideal. It also makes it harder to test as you are going to have to ensure that WindsorContainer gets configured appropriately.

A better solution is to add a dependency in the contructor for IKernel. If this class is resolved via the container, then it will resolve IKernel to a reference of the current Windsor MicroKernel object (which WindsorContainer inherits from). You can then use the reference to kernel to call its Resolve() method. Having the kernel injected now means it is now elementary to pass in a mock in your test code, mitigating the need to have all your castle.config configuration for your unit tests.

public class SomeClass : ISomeClass
{
    private IKernel _kernel;
    public SomeClass(IKernel kernel)
    { 
        _kernel = kernel;
    }

    public void SomeMethod(string name)
    {
        if (name == "david")
        {
            var class1 = _kernel.Resolve<IClass1>();
        }
        else
        {
            var class2 = _kernel.Resolve<IClass2>();
        }
    }
}

Sunday, 24 May 2009

Examples of log4net PatternLayout output

log4net has a lot of options when it comes to defining what you write to your log. While all the patterns are documented, it is useful to see a sample output from some code. Here is the output produced from some of the patterns available:

Pattern Class ‘BaseClass’ Class ‘SubClass’
appdomain log4netPatterns.vshost.exe log4netPatterns.vshost.exe
date 2009-05-24 16:37:26,578 2009-05-24 16:37:26,640
file C:\Dev\GoogleCode-Gardiner\trunk\Log4netPatterns\log4netPatterns\Program.cs C:\Dev\GoogleCode-Gardiner\trunk\Log4netPatterns\log4netPatterns\Program.cs
identity    
location log4netPatterns.BaseClass`1.MyMethod(C:\Dev\GoogleCode-Gardiner\trunk\Log4netPatterns\log4netPatterns\Program.cs:32) log4netPatterns.SubClass.MyMethod(C:\Dev\GoogleCode-Gardiner\trunk\Log4netPatterns\log4netPatterns\Program.cs:49)
level DEBUG DEBUG
line 32 49
logger log4netPatterns.BaseClass`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]] log4netPatterns.SubClass
message BaseClass SubClass
method MyMethod MyMethod
property {log4net:HostName=morgan} {log4net:HostName=morgan}
timestamp 45968 46015
thread 2116 2116
type log4netPatterns.BaseClass`1 log4netPatterns.SubClass
username MORGAN\David MORGAN\David
utcdate 2009-05-24 07:14:41,468 2009-05-24 07:14:41,515

Of particular interest is the difference between logger and type. For the SubClass class, they result in the same output, but for the BaseClass logger is a lot more verbose (especially if your generic type happens to be from a strongly-signed assembly!). Using logger will give more detailed information but at the expense of larger log files.

Methodology

Because some of the patterns vary their output if you are in a base class or an inherited class, I created a simple class hierarchy, and also included use of generics.

public class BaseClass<T>
{
   private ILog _log;

   public BaseClass()
   {
       _log = LogManager.GetLogger(typeof (BaseClass<T>));
   }

   public virtual string MyMethod(T stuff)
   {
       _log.Debug("BaseClass");

       return "ha";
   }
}

public class SubClass : BaseClass<string>
{
   private ILog _log;

   public SubClass()
   {
       _log = LogManager.GetLogger(typeof (SubClass));
   }

   public override string MyMethod(string stuff)
   {
       _log.Debug("SubClass");

       return "ho ho";
   }
}

The project that included this code was strongly signed, to allow any effect this might cause to be evident.

Wednesday, 13 May 2009

Blog moved to http://david.gardiner.net.au

I’ve decided to move my blog to a custom URL. It is still hosted by blogger, and the old address should continue to redirect to http://david.gardiner.net.au. If you are subscribed via a feed, then you shouldn’t need to change anything either.

I wonder what that will do to my page rank?

Thursday, 7 May 2009

How to mock a serial port

This question came up on the Rhino Mocks list recently, and it interested me as the application we’re working on has to talk to serial ports too.

Two common themes emerged:

  1. Write a “thin” interface for serial port operations and create a thin wrapper class that implements this interface and calls SerialPort directly. You can then mock out the interface easily.
  2. To test the wrapper, you can make use of the com0com null-modem emulator.

I suspect there would still be a bit of effort to get the com0com emulator working properly, but it sounds promising.