When unit testing a class that relies on app settings you don't want to be setting up web.config to get it running. I realised today that app settings are a dependency of a class. Therefore they must be injected by the IoC container. I'm using Ninject...

I have this in my web.config:
<appSettings> <add key="bar" value="1234" /> </appSettings>

I want to inject that value into a class constructor as below:

class Foo {
  public Foo(AppSetting bar)
  { ... }
}

AppSetting is a simple wrapper around a string:
class AppSetting {
  public AppSetting(string value) { Value = value; }
  public string Value { get; private set; }
}

I then configure Ninject with:
Bind<AppSetting>().ToProvider<AppSettingProvider>();

Where AppSettingProvider is:
class AppSettingProvider : Ninject.Core.Creation.IProvider
{
    public object Create(Ninject.Core.Activation.IContext context)
    {
        return new AppSetting(WebConfigurationManager.AppSettings[context.Target.Name]);
    }

    public Type GetImplementationType(Ninject.Core.Activation.IContext context)
    {
        return typeof(AppSetting);
    }

    public bool IsCompatibleWith(Ninject.Core.Activation.IContext context)
    {
        return WebConfigurationManager.AppSettings[context.Target.Name] != null;
    }

    public Type Prototype
    {
        get { return typeof(AppSetting); }
    }
}

The end result is a class that can be trivially unit tested, since it never calls the configuration API directly. Also, there was no need to create some complex abstraction around the API just to enable unit testing. In the future I can even change how and where app settings are stored (maybe using a database for example) all I'd have to do is make a new provider.

Ninject - in a word: awesome!

After beginning to use Snooze on a real project I realised it needed to be more extensible and more testable. So I re-wrote it!

The new code is now in the trunk: http://svn2.assembla.com/svn/snooze/trunk

A key extensibility point is the "ResourceContext" class. Before a resource is invoked, it's ResourceContext is initialised with relevant data such as HttpContext, invoke verb, GET view and file type. The base Resource class allows sub-classes to specify a particular ResourceContext sub-class, by the use of a generic type parameter. So when using Snooze in a web project it is easy to define extra context data that is always available to any resources. Instead of adding properties to a Resource class, the use of a context object allows data to be easily shared between a sub-resource and it's parent resource chain.

A Snooze resource also has a ResourceFactory object. The type of this is also generically typed so that a web project can provide a customized factory.

These changes make it easy to do things like test that a resource creates sub-resources (through the factory).

Wes Dyer's paper http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx has a great introduction to using Monads in C# and specifically how to create a continuation Monad that leverages the LINQ syntax.

After a lot of re-reading and coding, I managed to construct an asynchronous web request program.

UPDATE: Added Select<T> method for the monad so "let" syntax works.

class Program
{
    static void Main(string[] args)
    {
        var requests = new[]
        {
            WebRequest.Create(" http://www.google.com/") ,
            WebRequest.Create(" http://www.yahoo.com/") ,
            WebRequest.Create(" http://channel9.msdn.com/")
        };
        var pages = from request in requests
            select
                from response in request.GetResponseAsync()
                let stream = response.GetResponseStream()
                from html in stream.ReadToEndAsync()
                select new { html, response };

        foreach (var page in pages)
        {
            page(d =>
            {
                Console.WriteLine(d.response.ResponseUri.ToString());
                Console.WriteLine(d.html.Substring(0, 40));
                Console.WriteLine();
            });
        }

        Console.ReadKey();
    }
}

The actual web requests are deferred until the for loop invokes each "page" method. If you run the example a few times, you see that the results come back in a non-deterministic order, as expected with concurrent asynchronous operations. In addition, the web response stream is read asynchronously. So the main thread is never blocked - in fact that's why we need the Console.ReadKey() at the end, to stop the process ending before the results come back!

I had to change the type of the continuations from what Wes used. Instead of Func<T, Answer> I am just using Action<T>. The following code implements the continuation monad and the additional WebRequest and Stream extension methods.

delegate void K<T>(Action<T> c);

static class Continuations
{
    public static K<T> ToContinuation<T>(this T value)
    {
        return c => c(value);
    }

    public static K<U> SelectMany<T, U>(this K<T> m, Func<T, K<U>> k)
    {
        return c => m(x => k(x)(c));
    }

    public static K<V> SelectMany<T, U, V>(this K<T> m, Func<T, K<U>> k, Func<T, U, V> s)
    {
        return m.SelectMany(x => k(x).SelectMany(y => s(x, y).ToContinuation<V>()));
    }

    public static K<U> Select<U, T>(this K<T> m, Func<T, U> k)
    {
        return c => m(x => c(k(x)));
    }

    public static K<WebResponse> GetResponseAsync(this WebRequest request)
    {
        return send => request.BeginGetResponse(result =>
        {
            var response = request.EndGetResponse(result);
            send(response);
        }, null);
    }

    public static K<string> ReadToEndAsync(this Stream stream)
    {
        return send =>
        {
            byte[] buffer = new byte[1024];
            StringBuilder sb = new StringBuilder();
            Func<IAsyncResult> readChunk = null;
            readChunk = () => stream.BeginRead(buffer, 0, 1024, result =>
            {
                int read = stream.EndRead(result);
                if (read > 0)
                {
                    sb.Append(Encoding.UTF8.GetString(buffer, 0, read));
                    readChunk();
                }
                else
                {
                    stream.Dispose();
                    send(sb.ToString());
                }
            }, null);
            readChunk();
        };
    }

}

I imagine we will see something like this come out of the Volta project soon. Hopefully, it will form a generic asynchronous library that we can all use with anything that implements the Begin/End Invoke pattern.