C#

Adventures in F# - F# 101 Part 8 (Mutables and Reference Cells)

Matthew Podwysocki — Wed, 16 Apr 2008 00:08:37 GMT

Time for another adventure in F#, covering some of the basics of functional programming and F# in particular. Today we'll manage to look more at regular .NET integration and .NET programming. With the previous efforts, we've looked more at functional programming and in turn F# specific things, but want to show that you can do anything normally in F# that you can in C#. To me, F# is the perfect all-purpose language because it can do a lot of the things C# can do, but in turn, F# can do things much more elegantly than C# can, such as Pattern Matching.

Where We Are

Before we begin today, let's catch up to where we are today:

Today's topic will be covering imperative and object oriented programming in F#. There is a lot to cover, so let's get started. But there are a few administrative things to get out of the way first.

Learning F# ala Ted Neward?

Ted Neward recently announced on DotNetRocks Episode 332 that he's in the process of creating a class for F# for Pluralsight. That should be interesting to those who are interested in this series, as well as F# in general. Right now the community is rather small, so efforts like this should be rather rewarding I would hope. Ted's a pretty brilliant guy, so I'd imagine only the best. I'm hoping more details come out soon.

Pattern Matching in C#

Part of this series is intended to bring such concepts as Pattern Matching, Currying and other Functional Programming concepts to the C# developer. After all, the more C# language evolves, the more it seems to fall into the Functional Programming category. In previous posts, I showed how to relate currying to C# and it was less elegant than F# to say the least.

But, let's look at Pattern Matching. Bart De Smet has been posting recently on his blog about bringing the beauty of pattern matching to C#. So far it's been a good six posts into it and I urge you to go ahead and take a look at this series.

But when you read the series, it's all about getting into the low level and compiling expression trees to make the same simple beauty that is F#. Sure, it can be done in C#, but nowhere near as elegant. Performance is another issue that comes to mind with these.

Imperative Programming in F#

This section I'll lay out some of the basics of imperative style programming before I get into the full object oriented approach to programming. So, we'll cover just a few topics and then I'll feel comfortable moving onto the real parts of creating classes and such. We'll cover such things as void types and mutability in this section.

The unit Type

One of the first things I forgot to mention when describing F# functions and values in the unit type. Think of this as the void type in C# that you are used to. It's the type that doesn't accept or return a value. First, let's look at the typical C# program with the void type for Hello World.

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }

Now, let's go ahead and look at it from the F# perspective.

#light

let main() =

  printfn "Hello World"

main()

As you will see when you hover over our code is that it is a unit type. That in itself isn't all that interesting. But, what we'll run into is problems when functions return a value, but we're not all that interested in them. What happens? Well, F# will complain that your return value isn't compatible with the unit type, which is essentially true. So, how do you get around that? Let's walk through a simple unit test of a Stack written in F# and unit testing with the xUnit.net framework.

#light

#R @"D:\Tools\xunit-build-1252\xunit.dll"

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop() =

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> stack.Pop() |> ignore )

The real interesting part you should pay attention to is the last line. As you can see, I am using the forward operator to indicate that I really don't care what the function returns, just that I'm interested in that it executes. This is most likely during such functions that have some sort of side effect to them. I could also use the ignore function instead of the forward operator such as this:

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> ignore(stack.Pop()) )

This is very helpful in these cases where we really don't care about the return value, instead want to mutate the state of our given object, such as removing a value from a collection and so on.

Mutables

As I said in many posts before, by default all "variables" by which I mean values in F# are immutable. This is a standard in functional programming and all in the ML family. You can easily redefine a value by using the let keyword, but not actually mutate its state. But, since F# is a multi-purpose language on the .NET platform, mutable state can be had. To take advantage of this, mark your value as mutable. Then to change the value, just use the <- operator to reassign the value. Below is a simple example of this:

#light

let mutable answer = 42

printfn "Answer is %i" answer

answer <- 8

printfn "Answer is %i" answer

A key difference from the reassignment is that you cannot change the value type. Whereas I can redefine answer by keep using the let keyword, I can only keep my answer in this above example of the int type.

This can also apply to record types as well where you can change the fields. In the last installment, we talked about record types. Well, by default there as well, the fields for the record type are immutable. But, as with before, that can be changed. I of course like to caution people that mutable state takes a lot of the value proposition away from the side effect free programming that you gain with F# by default. But, nevertheless, you can still do it as noted below:

#light

type Person = { FirstName : string; mutable LastName : string; mutable IsMarried : bool }

let friend = { FirstName = "Courtney"; LastName = "Cox"; IsMarried = false }

friend.LastName <- "Cox-Arquette"

friend.IsMarried <- true

What I was able to do was define a Person record and change a couple of fields while using the <- operator and defining the fields as mutable. Yes, I could have used some scientific calculation or something, but this was easy.

Reference Cells

The last thing I want to touch on in this post is reference cells. You can think of these much as pointers in other languages or reference types. These of course can be of any type. The idea behind using these is to make updating fields as easy as possible. As with mutable fields, you cannot change the type once it has been assigned. To use these, you need to remember three basic operators

ref - Allocates a reference cell
:= - Mutates a reference cell
! - Reads the reference cell

Below is a quick example of mutation through reference cells:

#light

let x = ref 2

x := !x + 25

printfn "%i" !x

What the code example above lets me do is define a reference to the number 2. Then I can change that reference by reading the current x value and adding 25. Then I mutate the existing x value with the result.

Conclusion

This is just meant to be a brief overview to some imperative programming constructs that you might see in .NET, Java, C, C++ and so on. F# is a first class language all the way with constructs that support these things as well as your normal functional programming constructs. I hope we get to cover some of this at ALT.NET Open Spaces, Seattle at some point because I'm sure a lot of people will be interested. Until next time...

xUnit.net RC3 Just Released

Matthew Podwysocki — Thu, 10 Apr 2008 23:37:38 GMT

Well, Brad Wilson and Jim Newkirk must really be busy lately. After I talked about the release of xUnit.net RC2, just today, Brad announced the release of RC3. As always, you can find the latest bits here. This fixes a number of bugs and adds CruiseControl.NET and ASP.NET MVC Preview 2 support as well in addition to the Resharper 3.1 and TestDriven.NET support. For more information about it, check out Brad's post here. More or less, they are feature complete for version 1.0 and the only that I think really is needed at this point is a decent GUI runner and that's well acknowledged as something they are working on. Visual Studio integration would be nice as well...

For my other posts in this series, check them out here:

If you were in attendance at last night's RockNUG appearance, all tests for my demos were using xUnit.net, so I am actively using it right now and will be for my CMAP Code Camp appearance this weekend. However, I did not show the GUI runner because, well, it's not there yet, and instead, the console runner works just fine, thank you. So, go ahead and pick up the latest bits and give the team feedback!

One last note regarding Brad, he was recently interviewed by Scott Swigart and Sean Campbell over at How Software Is Built and gives some interesting insights in the open source world inside and outside Microsoft and his contributions to it. Very good interview and well worth the time to read.

Covering NUnit 2.4.7

Matthew Podwysocki — Tue, 01 Apr 2008 22:34:37 GMT

It's interesting that a flurry of releases of testing frameworks have been released lately with Gallio, xUnit.net and of course NUnit. Charlie Poole recently announced on a lot of the discussion boards I belong to recently that NUnit 2.4.7 was recently released. You can read all about what's been added here with the release notes.

What's New and Interesting?

What's interesting about this release? Well, NUnit no longer depends on log4net, thus getting rid of some dependency issues with regards to the applications under test. What's also interesting is that addition of the RowTest extension to allow multiple sets of arguments to be given to a test. This is the first one that's ever been incorporated into the core of NUnit.

Static Tests in NUnit?

As Andy Stopford noted in my blog yesterday regarding xUnit.net, Charlie recently checked in code to allow static methods for static methods to be tests as well as Setup and TearDown to be static as well. Jim Newkirk, the man behind NUnit and co-creator of xUnit.net, favors that approach of allowing statics. To me, I don't care as much with regards to Startup and TearDown with statics as most of my statics for testing F# is side effect free programming. As it should be with functional programming. Anyhow, what I'd like to see in NUnit is the support for something that I can do in xUnit.net:

#light

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"

open NUnit.Framework

let rec fib n =

  match n with 

  | 0 | 1 ->  0

  | n -> fib(n-2) + fib(n-1)

  | n when n < 0 -> failwith "Cannot be less than zero"

[<TestFixture>]

let FibOfOneShouldReturnZero() =

  let fibResult = fib(1)

  Assert.AreEqual(fibResult, 0)

If I saw something like this, I'd be a happy man. But until then, I can dream...

Conclusion

Go ahead and pick up your copy today of NUnit. It's been the old standby for many of my projects throughout my career and served me quite well. Next time I'll cover Gallio a little bit as I have neglected it, but it's a huge release.

IoC and Unity - Configuration Changes for the Better

Matthew Podwysocki — Fri, 28 Mar 2008 00:52:01 GMT

In my previous post about Unity and IoC containers, I made note of some changes in the latest drop of the Unity Application Block. As Grigori Melnik, the PM of the Unity and Enterprise Library team noted, Unity should be released in its final form on April 7th, so stay tuned. In the mean time, the latest drop of Unity was on March 24th, so go ahead and it pick it up.

Configuration Changes

As I noted from above, the public APIs really haven't changed all that much. Instead, most of the efforts recently have been around performance improvements in the ObjectBuilder base and the configuration of the container itself. I must admit that previous efforts left me a little cold with having to decorate my classes with the DependencyAttribute. Well, you shouldn't have to do that anymore, now that the TypeInjectionElement has been added so that you can map your constructor arguments and so on. Let's walk through a simple example of doing so.

First, let's go through my basic anti-corruption container that I use for Unity and any other container that I use for registration and so on.

namespace UnitySamples
{
    public static class IoC
    {
        private static IDependencyResolver resolver;
 
        public static void Initialize(IDependencyResolver resolver)
        {
            IoC.resolver = resolver;
        }
 
        public static T Resolve<T>()
        {
            return resolver.Resolve<T>();
        }
 
        public static T Resolve<T>(string name)
        {
            return resolver.Resolve<T>(name);
        }
    }
}

Remember this is just a quick spike sample of my anti-corruption container which was taken from Ayende. And then in order to configure my UnityContainer through the implementation of my IDependencyResolver interface. Let's take a brief look at that:

namespace UnitySamples
{
    public interface IDependencyResolver
    {
        T Resolve<T>(string name);
 
        T Resolve<T>();
    }
}

And then the implementation of the interface for Unity would look like:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    public class UnityDependencyResolver: IDependencyResolver
    {
        private IUnityContainer container;
 
        public UnityDependencyResolver()
        {
            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.Configure(container);
        }
 
        public T Resolve<T>()
        {
            return container.Resolve<T>();
        }
 
        public T Resolve<T>(string name)
        {
            return container.Resolve<T>(name);
        }
    }
}

Now, if you look at the constructor for the UnityDependencyResolver above, I am using the default container in order to configure my container. But, I have the option of specifying a name for it as well or even just an index. I could just easily change that code to this and it would work if I name my container default. This is a little bit of a change from before when I had to use the GetConfigCommand() method in order to configure the container which was a bit too chatty for my tastes.

            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers["default"].Configure(container);

So, the idea that I want to do is create an object graph so that I have classes with dependencies that have dependencies. Without doing AOP and some basic interception, we could take the approach of keeping around something like an IContext which would have our cross-cutting concerns in one location such as logging and whatnot in one area so your objects don't sit there with 16 constructor parameters, and instead has a context from which it can pull. This approach has worked for me in the past, so let's just go through that one right now.

First, let's look at the context that has those cross-cutting concerns and the actual implementation:

namespace UnitySamples
{
    public interface IContext
    {
        ILogger Logger { get; }
    }
}

And then the concrete implementation might look something like this:

namespace UnitySamples
{
    public class UnityContext : IContext
    {
        private readonly ILogger logger;
 
        public UnityContext(ILogger logger)
        {
            this.logger = logger;
        }
 
        public ILogger Logger
        {
            get { return logger; }
        }
    }
}

So, what I do here is inject my logger into my context, and probably anything else that might be cross-cutting as well. So, now in one of my classes, then I can accept the IContext in to do what I need it to do. That would look something like this.

namespace UnitySamples
{
    public class Customer
    {
        public string CustomerId { get; set; }
 
        public string FirstName { get; set; }
 
        public string MiddleName { get; set; }
 
        public string LastName { get; set; }
    }
 
    public class CustomerTasks
    {
        private readonly IContext context;
 
        public CustomerTasks(IContext context)
        {
            this.context = context;
        }
 
        public void SaveCustomer(Customer customer)
        {
            // Save customer
            context.Logger.LogEvent("Saving customer", LogLevel.Information);
        }
    }
}

I'm not doing anything special, instead, just showing how this pattern might apply. And then just tying it all together is my console application (sometimes my favorite UI for quick spikes).

namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IoC.Initialize(new UnityDependencyResolver());
            CustomerTasks tasks = IoC.Resolve<CustomerTasks>();
            tasks.SaveCustomer(new Customer{ CustomerId = "12345", FirstName = "Joe", LastName = "Smith", MiddleName = "Frank"});
        }
    }
}

But the more interesting part about this is the XML configuration. I know many people such as Ayende have declared war on XML configuration, but I think for this quick example it does quite well. If we start talking about complex object graphs, then I'd certainly agree and I'd rather do it programmatically. But, let's first look at how I'd wire up the whole thing in the app.config file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
    </configSections>
 
    <unity>
        <typeAliases>
            <typeAlias alias="string" type="System.String, mscorlib" />
            <typeAlias alias="ILogger" type="UnitySamples.ILogger, UnitySamples" />
            <typeAlias alias="ConsoleLogger" type="UnitySamples.ConsoleLogger, UnitySamples" />
            <typeAlias alias="DebugLogger" type="UnitySamples.DebugLogger, UnitySamples" />
            <typeAlias alias="IContext" type="UnitySamples.IContext, UnitySamples" />
            <typeAlias alias="UnityContext" type="UnitySamples.UnityContext, UnitySamples" />
            <typeAlias alias="CustomerTasks" type="UnitySamples.CustomerTasks, UnitySamples" />
        </typeAliases>
        <containers>
            <container>
                <types>
                    <type type="ILogger" mapTo="ConsoleLogger" name="defaultLogger"/>
                    <type type="ILogger" mapTo="DebugLogger" name="debugLogger"/>
                    <type type="IContext" mapTo="UnityContext">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="logger" parameterType="ILogger">
                                    <dependency name="debugLogger"/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                    <type type="CustomerTasks">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="context" parameterType="IContext">
                                    <dependency/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                </types>
            </container>
        </containers>
    </unity>
</configuration>

As you may notice from above, Unity gives us the ability to give type aliases so that we can reference the short names instead of the long ugly fully qualified type names by using the <typeAliases><typeAlias> nodes in the configuration. Much as before, we still register our types with a name, type and so on.

But, what's interesting is that we now have the ability to do type injection through a Unity extension called the TypeInjectionElement. This allows us to inject into the constructor and put in our parameters as need be. But we could also replace that with <method> or <property> in order to do method injection and property setter injection respectively.
Within the <param> element, we can specify our given injection element parameters. This allows us to specify the name of our given parameter, the type, but also for the dependency check, we can specify the name and type to alias the other <type> elements that we wish to get a reference of. We can also specify the values if we so desire of strings, integers and so on. Below is a simple example of using both dependency references and values.

<constructor>
    <param name="logger" parameterType="ILogger">
        <dependency name="debugLogger"/>
    </param>
    <param name="dbName" parameterType="string">
        <value value="AdventureWorks" />
    </param>
</constructor>

I find the best way to learn about these features usually isn't through documentation, although it's a nice thing to do, but instead the tests. I look for the functionality that I'm interested in and go deep. A project this size without good unit tests == FAIL in my opinion. Anyhow, this is better looking than it used to be and much more intuitive.

Interception Revisited

As Chris Tavares, the developer of Unity noted on my blog before was the fact that he could easily put in the interceptors from the ObjectBuilder2 since ObjectBuilder2 is modular and Unity is built upon it. It shouldn't have been news, because I've been working on that myself to get lightweight interception to work on it. Maybe when I get it fully implemented I'll share it. But in the mean time, it's just a spike.

Conclusion

I think this approach has helped in the XML configuration goo that had been a bit confusing. I didn't want to clutter my domain models and processing code with excess attributes stating intent, and would rather keep it clean. This makes a step in that direction. In the next installation of looking at IoC will revolve around Spring.NET and AOP in the Enterprise, so stay tuned... Until next time...

IoC and Unity - The Basics and InterceptionIoC and Unity - The Basics and Interception

Matthew Podwysocki — Wed, 26 Mar 2008 06:33:03 GMT

I realize it's been a while since my last post on Inversion of Control containers and looking at Unity as one of them. Since that time, Scott Hanselman linked to some of the comparisons that I did for IoC containers here. I'll be the first to admit that the look was a bit naive, but to get you all interested in looking at IoC container and how they can improve your applications. It was suggested here that my posts weren't a complete comparison, although in my previous posts I covered a lot of those topics. Even so, after talking with said individual, I need to cover more ground on the basics and dive deeper into the details.

Where We Are

Before we begin today, let's see what we've already covered in the past:

IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

So, we have a bit of back history, but I think I dived too far into things without giving some of the back story.

DI Frameworks Galore

As Scott Hanselman noted, there are a number of IoC containers in the .NET Space. Most of these I was already aware of and played with, so I'm only going to list the ones I've played with. Here they are in no particular order:

So, as you can see, there are plenty to choose from. They all serve basic IoC needs and I'll talk about that a little bit more later.

Getting Back to Basics

When we talk about Inversion of Control and dependency inversion principle, we're talking about loosely coupled applications. It follows the Hollywood Principle which is the trite "Don't call use, we'll call you" mantra. In a way it means that those dependencies that you have inside your class, say your Logger and its associated formatter. In the tightly coupled world, you would have a private member of a Logger. Instead, what you would have in the other case is an interface or abstract class that would represent the functionality of that logger, and that instance given to your class. Throw on top of that a container to manage those dependencies to those interfaces and mappings to concrete classes. Also, your container can manage the object lifetimes as well. Ayende shows how easy it is to create a simple container, although it misses an important point about lifetime management.

To put it succinctly, to be a container should satisfy the following requirements:

Configuration - Registering types and mappings through code, XML or script
Lifetime Management - How the lifetime of the objects are managed, singleton, transient, etc
Resolution - Resolve dependencies and instantiate
Extensibility - Be able to add new facilities for additional features (interception, AOP, and so on)

Before we get into any advanced topics, let's get into more detail. James Kovacs wrote in the March 2008 edition of MSDN Magazine called "Loosen Up - Tame Your Software Dependencies For More Flexible Apps". This article is a great start for those trying to understand dependency inversion and dependency injection. James walks through a simple application with tight coupling, and then works to loosen it. Once that is complete, Castle Windsor is introduced and walks through the XML configuration or using Binsor to auto-wire the container.

One of the more key points in this article and it came from Ayende is to have an anti-corruption layer for your IoC container. Yes, that's the same Domain Driven Design term in which we isolate things that don't conform to our given architecture and can translate from one context to another. Let's throw up a simple example of using this. Remember it's just a quick spike of an anti-corruption layer.

namespace UnitySamples
{
    public static class IoC
    {
        private static IDependencyResolver resolver;
 
        public static void Initialize(IDependencyResolver resolver)
        {
            IoC.resolver = resolver;
        }
 
        public static T Resolve<T>()
        {
            return resolver.Resolve<T>();
        }
 
        public static T Resolve<T>(string name)
        {
            return resolver.Resolve<T>(name);
        }
    }
}

So, what we have is an IDependencyResolver given to the singleton IoC container. Like I said, this isn't best practice as I haven't done any checking on whether the resolver was initialized or not. But, what we want is to expose the way of resolving dependencies. Now let's take a look at the IDependencyResolver interface and how that's used.

namespace UnitySamples
{
    public interface IDependencyResolver
    {
        T Resolve<T>(string name);
 
        T Resolve<T>();
    }
}

Not much to this but gives us the ability to resolve our dependencies by type, or by type and name. Pretty simple code here once again. But, if I wanted to suddenly use Unity as the backing store, I'd simply implement it as the following:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    public class UnityDependencyResolver: IDependencyResolver
    {
        private IUnityContainer container;
 
        public UnityDependencyResolver()
        {
            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
        }
 
        public T Resolve<T>()
        {
            return container.Resolve<T>();
        }
 
        public T Resolve<T>(string name)
        {
            return container.Resolve<T>(name);
        }
    }
}

So, all I'd have to do to switch from one container to another is just swap out the IDependencyResolver and I'm finished. But, unfortunately, there are some techniques that are partial to one container or another, so there may be some things I'd lose there. But for most cases, this pattern works and works well at that.

Of course loose coupling, dependency injection and using IoC containers are nice in terms of making unit tests easier, but as you can see, there's a bit more to it than that, including the lifetime management, interception, the flexibility of changing implementations and so on.

Interception and Aspect Oriented Programming

Aspect Oriented Programming (AOP) and basic interception are interesting pieces of some containers. This technique allows us to handle cross-cutting concerns such as logging, transaction management, security and so on at a different level instead of littering our code and domain model with checks everywhere. Instead, we centralize those concerns and have them intercept calls and do their work. Let's get some jargon straight here before we go any further. An aspect is the part that encapsulates the cross-cutting concern such as logging. These aspects can give advice, which is to alter the behavior of a given program. The advice is given at certain join points which is where the aspect advice and the program intersect. A group of these join points are called a pointcut.

Interception is a feature of some of the IoC containers out there. A few come to mind such as Castle Windsor, Spring.NET, LinFu, S2Container, Puzzle.NET and even ObjectBuilder2. These containers provide at least a basic level of interception, meaning that you can intercept calls to methods, analyze the contents of the method call, proceed with the call and even modify the return value. Since most containers support simple interception, I haven't found it more useful than logging or enforcing security on various things. However, it can be extended to support more robust Policy Injection style of programming such as you would find in the Policy Injection Application Block.

Interception in Unity?

Quite a bit has changed with Unity since I last blogged about it in terms of the configuration. You can grab the latest bits here. It would be nice to have changesets and such checked into CodePlex for things like this instead of zip files or MSIs, but oh well. Anyhow, most of the changes revolve around managing lifetimes and handling the parameters for constructor injection. You can read the tests and figure it out.

As I've covered before, right now simple injection in Unity is not supported at the moment. The intention is to have the Policy Injection Application Block fill that role. There is also PostSharp4Unity which can also fit that bill for quick fixes, but I want deep down support for simple interception. Conversations with Brad Wilson led me to ObjectBuilder2 and some spikes that they had with a customer DependencyContainer. So parts of me wondered why that wasn't leveraged at all. Let's take a look at what was implemented in the base of ObjectBuilder2.

Interception in ObjectBuilder2

ObjectBuilder2 was a project by Brad Wilson and Scott Densmore which took the original ObjectBuilder, which was really meant for CAB and not a real container, and made some changes and improvements. Such improvements also came with a few samples of things you can do with it such as a DependencyContainer sample. In here, there are a few interesting pieces. Most of which lie in the interception pieces. Let's take a look at each type below of the ones supported.

        public void InterceptInterface<T>(MethodInfo interfaceMethod,
                                          params IInterceptionHandler[] handlers)
 
        public void InterceptInterface(Type typeToIntercept,
                                       MethodInfo interfaceMethod,
                                       params IInterceptionHandler[] handlers)
 
        public void InterceptRemoting<T>(MethodInfo method,
                                         params IInterceptionHandler[] handlers)
 
        public void InterceptRemoting(Type typeToIntercept,
                                      MethodInfo method,
                                      params IInterceptionHandler[] handlers)
 
        public void InterceptVirtual<T>(MethodInfo method,
                                        params IInterceptionHandler[] handlers)
 
        public void InterceptVirtual(Type typeToIntercept,
                                     MethodInfo method,
                                     params IInterceptionHandler[] handlers)

Now with this, you can see there are three different ways of intercepting, through interfaces, virtual methods or through remoting. We also have the ability to intercept through attributes or through code. Let's walk through a test to see how intercepting through attributes might work.

            [Fact]
            public void InterceptViaAttributes()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterfaceAttributes>();
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }

Of course there wouldn't be tests in here without using xUnit.NET of course. Hope to cover that soon enough. Anyhow, as you can see, it's pretty simple to register types in here and then check the expectations through the recorder to see whether the actions happened. To find out what the ISpy and SpyInterfaceAttribtues are actually doing, let's dig through the code.

            public interface ISpy
            {
                void InterceptedMethod();
                void ThrowsException();
            }
 
            internal sealed class SpyInterfaceAttributes : ISpy
            {
                [InterfaceIntercept(typeof(RecordingHandler))]
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    throw new Exception();
                }
            }

What this class allows us to do is to register an intercepting interface handler, in this case the RecordingHandler. What we intend to have done is that we record a message once we're in the method. Then our interceptor can put in calls before and after our method call just to prove a point.

namespace ObjectBuilder
{
    public class RecordingHandler : IInterceptionHandler
    {
        readonly string message;
 
        public RecordingHandler()
        {
            message = "";
        }
 
        public RecordingHandler(string message)
        {
            this.message = string.Format(" ({0})", message);
        }
 
        public IMethodReturn Invoke(IMethodInvocation call,
                                    GetNextHandlerDelegate getNext)
        {
            Recorder.Records.Add("Before Method" + message);
            IMethodReturn result = getNext().Invoke(call, getNext);
            Recorder.Records.Add("After Method" + message);
            return result;
        }
    }
}

This IInterceptionHandler interface handles the basic interception tasks of doing some before and after work on the given method. Here it is doing nothing special but recording a message before and after intercepting the method call. I encourage you to dig through this a bit more and understand where it is coming from, because it's good stuff and heck, you might learn some IL emitting as well. It's a shame I didn't see some of this IP get rolled into Unity, but we can hope some of it does.

Interception in Castle Windsor

Like above with ObjectBuilder2, Castle Windsor has a lightweight interception capability as well. I covered this in a previous post, but I'll elaborate on it further. There isn't much on Windsor interception documentation, but you can read about that here. To take advantage of method interception, simply implement the IInterceptor interface which is marked below.

public interface IInterceptor
{
    void Intercept(IInvocation invocation);
}

And then we can implement a simple logger interceptor which goes ahead and logs the before and after information as well as anything else you might want to log that comes from the method signature such as arguments, method name, targets, etc. Here, I'm doing nothing special at all, but play around with the IInvocation interface to find out what you can do.

using Castle.Core.Interceptor;
 
namespace CastleSamples
{
    public class LoggingInterceptor : IInterceptor
    {
        private DebugLogger logger = new DebugLogger();
 
        public void Intercept(IInvocation invocation)
        {
            logger.Log("Before Method");
            invocation.Proceed();
            logger.Log("After Method");
        }
    }
}

Like I said above, I am doing nothing special here other than to show that I can log before and after calls, and I have the option of doing more whether I want to proceed with the method call or not. I can easily register the interceptor either through code, through Binsor or through the XML muck. An post of mine goes through that here.

To me, these lightweight interceptors are nice, but I don't get much value out of them just yet outside of logging and such. Ayende has similar thoughts about the uses of AOP in Windsor here. He also covers doing a Policy Injection Application Block style approach in Windsor as well here.

One off the topics discussed at DC ALT.NET was about using Windsor Interception to implement the Unit of Work pattern to implement undo logic for a WPF application. It was a pretty interesting approach to the issue and I'll definitely have to dig into that a little deeper as well. I'm hoping Phil McMillan starts blogging more anyways... But, obviously there are uses of interception and AOP in the enterprise and I'll get to that in the next post in the series.

Conclusion

As you can see, interception is an interesting topic that needs to be explored a bit more before I'd call this subject done. After all, I haven't touch most other containers, and I definitely want to get into AOP and Spring.NET as it is a topic I'd like to dive a little deeper into as well as AOP in the Enterprise model. Things that make the .NET rramework bend in all sorts of ways is always a worth cause. Anyhow, I hope this dive again into the subject is useful and any feedback is appreciated. Until next time...

IoC Container, Unity and Breaking Changes Galore

Matthew Podwysocki — Fri, 07 Mar 2008 08:13:25 GMT

Update: IoC and Unity - The Basics and Interception

As Grigori Melnik noted on my blog previously as well as his own, there was a brand new drop of the Unity Application Block as of March 4th. This by far was a huge update with a lot of breaking changes. That teaches me to use a CTP of any product and blog about it actively as it compares to other Inversion of Control (IoC) containers. Glad I didn't do a lot on ASP.NET MVC just yet but I have a few good projects going on the side with that now.

Where I've Been Before

As noted here before, I've been spending some time actively comparing the Unity Application Block to other IoC containers and what each offers. Let's get caught up to my previous posts:

I'm probably going to change the code on each one just so that you all don't get angry about code from me not working, so stay tuned, it will get done. But, keep in mind, it is still CTP, and I'd rather concentrate on the concepts as well.

What's Changed

As you may notice if you did any of the code snippets I published, they sure as heck don't build anymore. So, let's enumerate the changes made so far:

UnityContainer method Register<TFrom, TTo>() becomes RegisterType<TFrom, TTo>()
UnityContainer method Get<T>() becomes Resolve<T>
UnityContainer method SetSingleton<T> removed
UnityContainer method RegisterType<TFrom, TTo> accepts a LifetimeManager to create Singletons
Added ContainerControlledLifetimeManager and ExternallyControlledLifetimeManager
Removed DependencyAttribute NotPresentBehavior property and enum
Added UnityContainer CreateChildContainer method to create child sandboxes
Reversed the parameters for UnityContainer method RegisterInstance<T>(value, key) to RegisterInstance<T>(key, value)

As you can see, some of these changes can be seen as quite annoying especially if I were to have a method such as the following and I can't find the error until I sit and read the code through and through:

Old:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");

And sure enough, it blew up due to the fact that it seemed just fine because it was RegisterInstance<string>(string, string) and instead I had to change it to this to get it to work.

New:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("defaultFromAddress", "administrator@example.com");

Nothing from what I can tell changed in the XML configuration, but I prefer to register my types by code instead. The only thing I really like to switch out from time to time is a Logger of some sort.

Another interesting aspect is the concept of child containers in their own sandbox as it were. Take for example, we have two loggers, a DebugLogger and a ConsoleLogger. We have the ability to have these registered in two different child containers all managed by the parent. Let's walk through a simple example of this.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer parentContainer = new UnityContainer();
            IUnityContainer childContainer1 = parentContainer.CreateChildContainer();
            childContainer1.RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
            IUnityContainer childContainer2 = parentContainer.CreateChildContainer();
            childContainer2.RegisterType<ILogger, DebugLogger>(new ContainerControlledLifetimeManager());
 
            ILogger logger1 = childContainer1.Resolve<ILogger>();
            ILogger logger2 = childContainer2.Resolve<ILogger>();
            logger1.Log("Foo");
            logger2.Log("Bar");
        }
    }
}

What seemed a little annoying to me is that CreateChildContainer is not available from the IUnityContainer, and instead only from the UnityContainer concrete class instead. But as you can see, I create two loggers each in their own sandbox, one a DebugLogger and one the ConsoleLogger.

What I'd Like To See

As I've said before, I'm not entirely sold on the Unity Application Block as I like a lot of the other ones in the Open Source Community as well including Castle Windsor, StructureMap and Spring.NET. It's heartening that they are taking a lot of advice from the community to heart and having quick drops for public approval. When people are evaluating IoC containers, it's critical that you have a list of essential features that the container must support. You may also note that your needs for this may change from project to project, so don't assume that if it worked well here that it will suit your needs on all projects. Due diligence must be done in tool and framework analysis to get the right tool for the right job.

With that in mind, I have a few things that I'm looking for right now in an IoC container. Some of these requirements are as follows:

Must be lightweight (No heavy XML lifting required)
Must support interception and AOP with runtime weaving (compile time might be nice)
Should be opinionated so that I don't need to mark my dependencies in my constructor, instead match by name
When I ask for a logger, give me one and I don't care which
Support easy object registration through fluent interfaces

But like I said, it evolves quickly and changes from project to project. What's your list and why?

Further Thoughts About IoC

Nick Malik recently blogged about IoC container and their overuse in a two part blog series here and here. In his first post, he tends to think that people are religious about the use of IoC containers and not just the Dependency Injection pattern in particular. In the second post, he covers that the use of the IoC container is only as good as the team that understands its impact and applicability. Most tools have their limits and uses. Mocking containers have the same issue. Once you start mocking for parts of your tests, then there is a good chance for abuse and overuse as well. I see his point, but I disagree that many teams are not up for IoC containers and general good design practices of Dependency Injection.

Wrapping It Up

Next time, I'd like to get into the extensibility model of each container in terms registering extensions and so on. In the mean time, I hope you go and evaluate your needs for an IoC container, even whether you need one or not. Until next time...

IoC Containers, Unity and ObjectBuilder2 - The Saga Continues

Matthew Podwysocki — Tue, 04 Mar 2008 08:15:34 GMT

Update: Fixed code changed from CTP and More in the series:

IoC Container, Unity and Breaking Changes Galore

I just wanted to revisit the whole Unity Application Block just once more to look at a few more things including handling parameters, instances and so on. If you hadn't seen, there was another source drop of Unity as of 2/26, so if you haven't picked it up, feel free to do so here.

So, we're going to continue our look at DI and IoC containers as they pertain to different needs. I'm not going to be a gloryhound about any particular IoC container, instead, just lay out how each one does its job and you decide whether you want to use it or not. And that's the main point I want to emphasize here that each tool has its purpose and its needs that it solves and it's up to you do decide whether it meets your needs and programming style.

Where We Are

Anyhow, I covered the Unity Application Block in a few other posts lately as it relates to other Inversion of Control (IoC) containers. I covered the basics with the Unity Application Block, StructureMap and Castle Windsor. Check them out before we go any further today:

Now that we're caught up to where we have been, let's dive into the other subjects in the same area of concern. Unity has an interesting way of dealing with several issues that I want to cover in respect to other IoC containers. And they are:

Managing Instances and Parameters
Method Call Injection
Unity Application Block versus ObjectBuilder2

Managing Instances or Parameters?

The previous two times, we talked about constructor injection and setter injection, but not really about managing simple types and mapping them to our constructors. It's usually a simple thing, but yet, we have three different ways of attacking the very same problem. That's the very point of these blog posts to point that out and it's once again echoed here.

To set up this scenario, we have a simple SmtpEmailService which is used to send emails to users in our system. It's a pretty naive sample, yet will illustrate some simple constructor injection with both simple and complex types. We're going to inject a default from address and a logger into our service and go from there.

We'll start with our Unity sample of how we are going to map those simple and complex types to the constructor. Let's start off with the basic logger interface and implementation. I'll only post this part once as it will apply the same to each of the samples.

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

And once again, we have our concrete implementation with the console logger.

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now, let's tie it together with the point of today's post, the SmtpEmailService. We will have two parameters in this scenario, the default email address, and the logger used for logging.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note, I'm using the DependencyAttribute to decorate the parameter defaultFromAddress. This correlates to the key specified in the config file or when you register an instance, and I'll show you that later.
Let's take a look at the program.cs to use the XML config file to wire up our instances.

using System.Configuration;
 
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

The above code is pretty standard as we've used before, so real surprises here. So, let's take a look at the XML configuration necessary to make this work:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity"
                type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                  Microsoft.Practices.Unity.Configuration" />
    </configSections>
    <unity>
        <containers>
            <container>
                <types>
                    <type type="UnitySamples.ILogger,UnitySamples"
                          mapTo="UnitySamples.ConsoleLogger,UnitySamples"
                          lifetime="Singleton"/>
                </types>
                <instances>
                    <add name="defaultFromAddress" type="System.String" value="administrator@example.com" />
                </instances>
            </container>
        </containers>
    </unity>
</configuration>

What I did is that I utilized the instances node and then add an instance called defaultFromAddress. This node is only used to initialize simple types such as strings, DateTimes, System.Doubles, System.Int32 and so on. Then I can set the value as well. So, if I want to initialize complex types in the types node and the simple types in the instances node.

But, we can also register things through the regular programmatic interfaces as well such as this:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            container
                .Register<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
                .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you note, I used the fluent interfaces approach to register the ConsoleLogger as well as the instance of type string which had my value and the key I wanted to use. The first value I use is the value, and the second is the key I want to use to correlate to my DependencyAttribute.

Now, let's look at the StructureMap instance using the same approach. The only pieces I intend to show are just the pieces I changed. So, let's take a look at the SmtpEmailService once again.

namespace StructureMapSamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService(string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note from above, I had no need for the dependency attribute or anything like that. I haven't bothered to put the PluginAttributes or anything like that either as I want to do XML config way. So, let's next look at the program.cs which does the simple email wireup.

using StructureMap;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

And then we wire things up with our StructureMap.config file. Note that we set up things through an Instance node and then set the constructor injection parameters through property nodes.

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
    <Aseembly Name="StructureMapSamples"/>
  <PluginFamily Type="StructureMapSamples.ILogger" Assembly="StructureMapSamples" DefaultKey="Console" Scope="Singleton">
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.ConsoleLogger" ConcreteKey="Console" />
    </PluginFamily>
  <PluginFamily Type="StructureMapSamples.SmtpEmailService" Assembly="StructureMapSamples" DefaultKey="EmailService">
      <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.SmtpEmailService" ConcreteKey="SmtpEmailService" />
      <Instance Key="EmailService" Type="SmtpEmailService">
          <Property Name="defaultFromAddress" Value="administrator@example.com" />
          <Property Name="logger" Key="Console" />
      </Instance>
  </PluginFamily>
</StructureMap>

I tidied up the XML configuration a bit after taking Jeremy Miller's advice and trying to collapse it down as much as possible. I'm sure I still don't have it to the smallest amount possible, but at least it's legible. Now, let's go ahead and use the DSL for configuration instead of the simple program.cs we have above.

using StructureMap;
using StructureMap.Configuration.DSL;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            StructureMapConfiguration.UseDefaultStructureMapConfigFile = false;
            StructureMapConfiguration.BuildInstancesOf<ILogger>()
                .TheDefaultIsConcreteType<ConsoleLogger>().AsSingletons();
            StructureMapConfiguration.BuildInstancesOf<SmtpEmailService>().TheDefaultIs(
                Registry.Instance<SmtpEmailService>().UsingConcreteType<SmtpEmailService>()
                    .WithProperty("defaultFromAddress").EqualTo("administrator@example.com"));
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you can see from above, it's a pretty simple thing to use the more fluent interfaces here as well to register what we're interested in. We're making sure it doesn't use the default StructureMap.config file and then build up an instance of an ILogger as a singleton, and then use the injection on the SmtpService to set the defaultFromAddress. The ILogger it should automatically figure out itself.

Now, let's finally move onto Castle Windsor. I must admit, I'm most familiar with Castle Windsor, but I'm learning something new about each of these every day, which is a good thing. So, the only classes I really need to show is the program.cs and the configuration file to show what has changed. So, let's start with the program.cs file:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

This is a pretty simple example of using the XmlInterpreter which reads the XML configuration file to read what we want to set. And then our XML configuration file should look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="castle"
            type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
    </configSections>
    <castle>
        <components>
            <component id="emailservice.smtp"
                type="CastleSamples.SmtpEmailService, CastleSamples">
            <parameters>
                <defaultFromAddress>administrator@example.com</defaultFromAddress>
            </parameters>
        </component>
        <component id="logger.console"
                       service="CastleSamples.ILogger, CastleSamples"
                       type="CastleSamples.ConsoleLogger, CastleSamples"
                       lifestyle="singleton" />
        </components>
    </castle>
</configuration>

I could have also specified the logger as well as a parameter by noting it inside the parameters node such as this:
<logger>${logger.console}</logger> to specify that it uses the ConsoleLogger, but it's not really necessary to do so.

Instead, let's use the XML free way of configuration just to prove a point we can do it both ways:

using System.Collections.Generic;
using Castle.Core;
using Castle.Windsor;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer();
            container.AddComponentWithLifestyle("logger.console", typeof (ILogger), typeof (ConsoleLogger),
                                                LifestyleType.Singleton);
            Dictionary<string, object> properties = new Dictionary<string, object>();
            properties.Add("defaultFromAddress", "administrator@example.com");
            container.AddComponent("emailservice.smtp", typeof (SmtpEmailService));
 
            SmtpEmailService service = container.Resolve<SmtpEmailService>(properties);
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

So, as you can see, it's pretty simple to set the parameters on our SmtpEmailService through the use of a Dictionary<TKey, TValue> generic collection. The rest is just plain simple.

Method Call Injection

The Unity Application Block introduces another concept called method call injection. Yes, that's right, instead of using constructor injection or setter injection, you can use method call injection. The basic premise is that you can inject any method as you would for a constructor or setter.

When would you use this though? If you read the documentation, it lays out the explanation as follows:

You want to instantiate dependent objects automatically when your instantiate the parent object
You want a simple approach that makes it easy to see in the code what the dependencies are for each class
The parent object requires a large number of constructors that forward to each other, making debugging and maintenance difficult
The parent object constructors require a large number of parameters, especially if they are of similar types and the only way to identify them is by position
You want to hide the dependent objects by not exposing them as properties
You want to control which objects are injected by editing the code of the dependent object instead of the parent object or application

By default unless any of this matches your criteria, you should just go ahead and use constructor injection. But, let's walk through a small sample of using method injection:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private string defaultFromAddress;
        private ILogger logger;
 
        [InjectionMethod]
        public void Initialize([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

The rest of our program shouldn't have to change with this scenario. But, as you will note from above, we decorated our Initialize method with an InjectionMethodAttribute which makes it realize that instead of constructor injection, use this instead. And it works like a charm. I haven't run into a scenario yet where I would find it useful, but I find it interesting. If anyone does have a scenario that they've run into, please let me know.

Unity == ObjectBuilder2?

As you may have noticed, if you had downloaded the Unity Application Block, you'll notice that it is built upon ObjectBuilder2, but you may also notice that it hides a lot of functionality that it provides. When you are marking your classes with DependencyAttribute and other things, you will notice that there are two of them, one in Unity and one in ObjectBuilder2, so this got me curious on what else I was missing out on.

If you've played around with Enterprise Library in the past, you have probably dealt with ObjectBuilder. It was not the most delightful piece of code I've ever had to deal with and not very intuitive. Brad Wilson and Scott Densmore took it upon themselves to rewrite this into a much more usable piece of code. You can download the original and unencumbered ObjectBuilder2 from CodePlex here.

Take a look at the CodePlex DependencyInjection project and its associated tests in Tests.CodePlex.DependencyInjection for a good idea on how well Brad and Scott did with their DI framework. The best way to learn about any framework is to read the tests or specs (BDD style of course). Let's look at two ways of doing code interception using the DI framework with using code and using attributes.

            [Fact]
            public void InterceptViaAttributes()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterfaceAttributes>();
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }
 
            [Fact]
            public void InterceptViaCode()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterface>();
                container.InterceptInterface<SpyInterface>(typeof(ISpy).GetMethod("InterceptedMethod"),
                                                           new RecordingHandler());
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }

Ok, so you may note that we registered this with an ISpy interface. Then we have two implementations, one with code and one using attributes. Let's now inspect that code.

            public interface ISpy
            {
                void InterceptedMethod();
                void ThrowsException();
            }
 
            internal sealed class SpyInterface : ISpy
            {
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    Recorder.Records.Add("In Method");
                    throw new Exception();
                }
            }
 
            internal sealed class SpyInterfaceAttributes : ISpy
            {
                [InterfaceIntercept(typeof(RecordingHandler))]
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    throw new Exception();
                }
            }
        }

As you may note, we have two methods that we're interested in, the InterceptedMethod and the ThrowsException method. Then we can test through a Recorder that in fact the code was hit. xUnit.net is used quite frequently throughout the code as it is a project also by Brad and Jim Newkirk. Overall, I'm very impressed with this code and I wish it had made more of an impact.

Chris Tavares and others from the Unity team have taken it upon themselves to redo a lot of the guts of ObjectBuilder2 as they continue to extend Unity. For AOP, the plan is to include the Policy Injection Block into the solution, whereas ObjectBuilder2 already had this piece of functionality and does it quite well. Some of it seems to be right now a little less featured than ObjectBuilder2 at this point, but that can change. I have hopes for Unity, but ObjectBuilder2 did a lot of these things that it claims to do, just a little bit better.

Wrapping it Up

Here wraps up another installment of looking at IoC containers and the various frameworks associated with it. I hope that it whets your appetite to not only understand these containers, but see how they work deep down and see which matches your programming style. Get to know your tools just a little bit better and find out what good quality code can be. I hope you can take this to heart and see what works for you.

IoC and the Unity Application Block Once Again

Matthew Podwysocki — Wed, 27 Feb 2008 00:31:34 GMT

Update: Fixed code changed from CTP and More in the series:

After the reaction of my last post of talking about IoC and the Unity Application Block, I thought I'd include a few more samples of using Unity and how they compare with other IoC containers. I realized after my first one, that I didn't give any love to StructureMap and I'm going to fix that for a brief sample as well. I realize there are plenty of IoC containers out there including Spring, but quite frankly I've found it heavier than most, so I'm going to stick with Unity, Castle Windsor and StructureMap for this example.

Before I continue, check out David Hayden's screencast of IoC with ASP.NET MVC for some more interesting ideas regarding IoC and Unity.

Setter Injection versus Constructor Injection

I've been down the road of constructor injection versus setter injection. My opinion is that you try to inject the most you can through your constructor such as in a Model View Presenter, injecting the View and the Service Layer. Now, you may have cross-cutting concerns such as logging that you may want to swap out, but putting it in the constructor can just get ugly and you can set a default logger in your class anyways such as a NullLogger. Martin Fowler, as always, covers this topic here and it's quite interesting as it is an open debate.

The other option I've done down this road was to create an IContext interface which is injected through the constructor that has some of the cross-cutting concerns wrapped up into it, but for now, let's just walk through a sample of having setter injection as well.

Get Down to Details

Now that we got all the other stuff out of the way, let's go ahead and set up some basic examples in Unity, Castle Windsor and StructureMap doing setter injection. I'll basically take the code from last time and apply it here as well. So, let's start out with the Unity Application Block Sample:

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

And we have two implementations, the NullLogger (the default) and the ConsoleLogger (the override). Let's go through each of those.

namespace UnitySamples
{
    public class NullLogger : ILogger
    {
        public void Log(string message)
        {
            // Do nothing
        }
    }
}

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now that I have these two implementations, I won't bother repeating these for the others unless they specifically change, which they shouldn't. Now, to my implementation details of my CustomerTasks object.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        [Dependency]
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

As you may note, I set the default implementation of my logger to a NullLogger because by default, I don't care about logging, so it's about the same as a NoOp. But, if I want to change that, I can through my setter injection. This goes for any cross-cutting concern. I also marked my Logger property with the DependencyAttribute which basically says that give me the ILogger instance registered when you go through the container to create it. This of course requires class modification, so it's not a simple rip and replace as it was with constructor injection. So, now let's look at the implementation of our configuration, much as before.

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            CustomerTasks tasks1 = container.Get<CustomerTasks>();
            CustomerTasks tasks2 = container.Get<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

And the configuration file will look much like before as:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity"
             type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                   Microsoft.Practices.Unity.Configuration" />
  </configSections>
  <unity>
    <containers>
      <container>
        <types>
          <type type="UnitySamples.ILogger,UnitySamples"
                mapTo="UnitySamples.ConsoleLogger,UnitySamples" 
                lifetime="Singleton"/>
        </types>
      </container>
    </containers>
  </unity>
</configuration>

Now, let's do the same thing with Castle Windsor. Most of the code will be the same from our Unity sample as I can't imagine that much will change except that I don't need to register the DependencyAttribute on the CustomerTasks object. Let's first look at the changed CustomerTasks object.

namespace CastleSamples
{
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

Now, let's look at the program.cs file to see how really nothing changed at all from our perspective:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();
        }
    }
}

And then our config file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="castle"
        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
  </configSections>
  <castle>
    <components>
      <component id="customertasks" type="CastleSamples.CustomerTasks, CastleSamples" lifestyle="transient" />
      <component id="logger.console" service="CastleSamples.ILogger, CastleSamples" type="CastleSamples.ConsoleLogger, CastleSamples" lifestyle="singleton" />
    </components>
  </castle>
</configuration>

So, in reality, nothing changed from our constructor injection versus our setter injection implementation for Castle Windsor. That to me is pretty cool... But, now, let's move our attention to StructureMap. Let's walk through only the code that has changed. I'm only going to use the one with the StructureMap.config file and not the fluent interfaces just yet. I know more of the config file and not enough of the interfaces to be effective. Let's go through what really changed. In reality, everything is the same from the Castle Windsor implementation and the StructureMap one except for the Program.cs and the StructureMap.config file, so let's look at the Program.cs first.

using StructureMap;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            CustomerTasks tasks1 = ObjectFactory.GetInstance<CustomerTasks>();
            CustomerTasks tasks2 = ObjectFactory.GetInstance<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

And to make sure our object is a singleton, let's make our StructureMap.config file and walk through the details:

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
  <PluginFamily Type="StructureMapSamples.ILogger" Assembly="StructureMapSamples" DefaultKey="Console">
    <Interceptors>
      <Interceptor Type="Singleton" />
    </Interceptors>
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.ConsoleLogger" ConcreteKey="Console" />
    </PluginFamily>
  <PluginFamily Type="StructureMapSamples.CustomerTasks" Assembly="StructureMapSamples" DefaultKey="CustomerTasks">
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.CustomerTasks" ConcreteKey="CustomerTasks">
      <Setter Name="Logger" Key="Console" />
    </Plugin>
  </PluginFamily>
</StructureMap>

If you're familiar with StructureMap, the config file should make sense to you as I'm creating an ILogger with the default implementation being the ConsoleLogger and then we make sure it is a singleton through the use of an interceptor. Then we also do a setter injection through our plugin of the CustomerTasks with setting the Logger property to the key of Console. Pretty simple and straightforward.

So, as you can see, they are very similar in nature, but attack the problem in different ways. That's the beauty of it all, just determine your needs and your programming style and then the pick of your IoC container should come into line with that. These are pretty simple and naive samples, but I just want to whet your appetite to open your mind and look for yourself at these containers for yourself.

AOP with PostSharp and Unity?

Gael Fraiteur recently posted on the altdotnet list about the new release of PostSharp. Gael blogged about that here. A couple of things intrigued me about it, including the license change to LGPL for the runtime and GPL for the code. This requires a commercial license should you want to redistribute it with your application. But, I'll leave that up to him and the lawyers to figure out.

But, let's get back to Unity for just a second. Gael recently announced on the Unity Application Block discussion list about including an extension to support PostSharp which you can find here. You can find the code in particular to do this, plus the Stoplight sample converted at GoogleCode here under PostSharp4Unity. Get your favorite SVN client and pull it down.

So, let's take my basic example from above and try to get it using the default constructors instead of the approach of calling the container to get ourselves an instance. A good approach is to keep the container out of your way and produce cleaner code. A downside of using IoC containers is that they can litter up your code. PostSharp4Unity allows us to create an extension for Unity and use our default constructors.

First, let's create a Unity container provider so that we can initialize our container programmatically. Create a UnityContainerProvider in your project that inherits from the IUnityContainerProvider. That code should look like this:

using Microsoft.Practices.Unity;
using PostSharp4Unity;
using UnitySamples;
 
namespace UnitySamples
{
    public sealed class UnityContainerProvider : IUnityContainerProvider
    {
        private readonly IUnityContainer container;
 
        public UnityContainerProvider()
        {
            this.container = new UnityContainer()
                .Register<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
        }
 
        public IUnityContainer CurrentContainer
        {
            get { return this.container; }
        }
    }
}

Now we also have to mark our assemblyinfo.cs with our default UnityProviderContainer, so open up your assemblyinfo.cs and put this info in there:

using PostSharp4Unity;
using UnitySamples;
 
[assembly: DefaultUnityContainerProvider(typeof(UnityContainerProvider))]

Ok, done and now we have to mark our class that we want to mark our configurable objects that we want to control with PostSharp. So, open CustomerTasks and modify it to this:

using Microsoft.Practices.Unity;
using PostSharp4Unity;
 
namespace UnitySamples
{
    [Configurable]
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        [Dependency]
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

So, then our program.cs can look like this now:

namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            CustomerTasks tasks1 = new CustomerTasks();
            CustomerTasks tasks2 = new CustomerTasks();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

But, in order for PostSharp to do its magic, we need to make sure it's part of our compilation targets in our .csproj file. So, I hand munged mine and got it to work like this:

</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(PostSharpDirectory)PostSharp.targets" Condition=" Exists('$(PostSharpDirectory)PostSharp.targets') " />
</Project>

Then I'm able to get the magic of PostSharp to do its work. Pretty slick!

Wrapping It Up

So, I hopefully whetted your appetite for these IoC containers for you to go and do a comparison on your own. Each container has a different way of configuring itself and each solves a different problem set. It's up to you to decide which one to use. Along the way you can have a pretty cool journey though in learning deciding what works for you and what doesn't. Until next time, and hopefully an F# related post...

IoC and the Unity Application Block - Going Deeper

Matthew Podwysocki — Sat, 23 Feb 2008 00:12:12 GMT

Update: Fixed code changed from CTP and More in the series:

I thought after my recent F# post, I'd get back to the Unity post that was halfway done before the firestorm began...

In a previous post, I showed how easy it was to create a basic application using the Unity Application Block. I'm always finding new ways to solve my problems and new tools to do it. Since Inversion of Control (IoC) containers are near and dear to my heart, I thought I'd investigate to see whether it meets my needs or not. It's something you need to determine on your own, whether it works for you. Some like Spring.NET, others StructureMap, Castle Windsor and so on.

Purse Fight???

Now, there has been some rather heated discussion around the Unity Application Block on the altdotnet mailing list. The discussion even got heated enough for the ALT.NET Pursefight blog to come back into action after a long hibernation with a post called "Dear Idiots"...

Compare/Contrast with Windsor

Anyhow, today I will focus on a little compare/contrast with Castle Windsor just to show the different styles used. I'm not going to say one is better than the other, because quite frankly, that's up to you to decide... I want to thank Dustin Campbell for his help in getting a better code formatter via this post here.

So, let's just take a sample from before and have our ILogger and create a singleton first using the Unity Container. So, we will go ahead and use the ILogger interface, and create a concrete implementation of that called ConsoleLogger, inject it into the constructor and then call the Log method from within the CustomerTasks class. Pretty simple scenario especially when dealing with cross cutting concerns. So, the code to do this is below.

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

Now that we have a simple, undecorated interface, let's actually implement it in code for a simple console logger. Not practical for real use, but shows a point.

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public ConsoleLogger()
        {
            Console.WriteLine("Hello from constructor");
        }
 
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now that we have that, let's create a class that takes an ILogger through constructor injection.

namespace UnitySamples
{
    public class CustomerTasks
    {
        private readonly ILogger logger;
 
        public CustomerTasks(ILogger logger)
        {
            this.logger = logger;
        }
        public void SaveCustomer()
        {
            logger.Log("Saved customer");
        }
    }
}

Ok, time to actually start up the UnityContainer by registering everything through code. It's a pretty simple operation. We want the ILogger instance to be a singleton instance. This happens during the registration process by calling the SetSingleton<T>() method off the container itself. Note the nice fluent interfaces for doing this component registration.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer container = new UnityContainer();
            container.RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();        
        }
    }
}

So, as you can see, no real config file was really necessary for me to do any of this. It was a simple registration process of creating a UnityContainer. But, that's not ideal, so let's set it as a singleton using the config file instead:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();        
        }
    }
}

You'll notice that the configuration is still kind of awkward for having to get the configuration section this way and I'm hoping for a cleaner registration soon enough. And the configuration file would look like this for the registration. Note that I'm setting the lifetime to Singleton. For those familiar with Castle Windsor, it should look pretty familiar.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity"
             type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                   Microsoft.Practices.Unity.Configuration" />
  </configSections>
  <unity>
    <containers>
      <container>
        <types>
          <type type="UnitySamples.ILogger,UnitySamples"
                mapTo="UnitySamples.ConsoleLogger,UnitySamples" 
                lifetime="Singleton"/>
        </types>
      </container>
    </containers>
  </unity>
</configuration>

So, now that we have this, let's run it and sure enough, the results are:

Hello from constructor
Saved customer
Saved customer

So, we notice that the constructor was called only once, which was our point all along. Now, let's mosey along and do the same with Castle Windsor. The only thing I want to change is the Program.cs and sure enough I can do that pretty easily and just change the namespaces. For brevity's sake, I won't repaste the code with just the namespace change, so let's actually just show the Program.cs below. First, I'll try using the component registration through the code itself.

using Castle.Core;
using Castle.Windsor;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer();
            container.AddComponentWithLifestyle("logger.console", typeof(ILogger), typeof(ConsoleLogger), LifestyleType.Singleton);
            container.AddComponent("customertasks", typeof(CustomerTasks));
 
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();
        }
    }
}

Well, once again, it's nice to show we can register through the code itself, but not super useful. Instead, things like that should get moved over to the config file instead. Let's redo the code to reflect that:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
 
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();
        }
    }
}

Ok, so our program looks much simpler now, so, let's move the stuff into the app.config and it should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="castle"
            type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
    </configSections>
    <castle>
        <components>
            <component id="customertasks" type="CastleSamples.CustomerTasks, CastleSamples" lifestyle="transient" />
            <component id="logger.console" service="CastleSamples.ILogger, CastleSamples" type="CastleSamples.ConsoleLogger, CastleSamples" lifestyle="singleton" />
        </components>
    </castle>
</configuration>

And of course we run this and get the same result as we expected as before. Now, what's cool is that none of my interfaces, nor implementations had any knowledge of my container, and so I can switch it out any time with no real harm to my components. That's what I like.

Container Behavior

Another interesting thing to note is how some containers handle ambiguous references. Ayende recently posted on the altdotnet list about how Unity versus Castle Windsor resolves. Jeremy Miller also chimed in as well with this.

With this particular pseudocode, Castle Windsor can resolve this, while the other containers will fail due to an ambiguous reference.

container.Register<IDisposable, SqlConnection>("SQL")
.Register<IDisposable, OracleConnection>("ORA");

container.Get<IDisposable>();

AOP in Unity???

In a previous post, I covered how you can do runtime weaving in Castle Windsor by implementing the IInterceptor interface and registering it through the config file. So, does the Unity Application Block support something like this? The answer is yes, but it's not out of the box. Instead, you can build a UnityContainerExtension that supports the Policy Injection Application Block (PIAB). Martijn Veken has built an extension to use the PIAB and you can read more about it here. So, the AOP really isn't baked into Unity, but who knows, it may in the future, or it may just reside only in the PIAB. Time will tell...

Conclusion

So, that's just the basics of a little Windsor and Unity bakeoff just to see some of the differences in philosophy. I'd encourage everyone to take a look at most containers and find out which one really fits your need and programming style. Competition and choice is a good thing. Until next time...

Adventures in F# - F# 101 Part 2

Matthew Podwysocki — Fri, 22 Feb 2008 01:48:43 GMT

I know it's been a little bit too long since I began this series from when I continued, but plenty of distractions came up along the way. I intend to go a little deeper today into what functional programming means and why you should care. As always, check out my previous post on the matter here.

Getting Sidetracked

Last night at the DC ALT.NET meeting, Craig Andera and I discussed Lisp, F# and functional programming as a whole. His language of the year was Lisp and I thought that was an interesting choice of the language to learn, but when you think about it, most good things in programming lead back to SmallTalk and Lisp... I had been hearing a bit about IronScheme, the IronLisp rewrite, so of course I had to check it out. Maybe this will be one of my future languages to learn, but I had enough exposure during my college years to last a little bit, so it's on the plan anyways.

Basic Introduction

So, just in case you missed the idea of functional programming and what it means, I have a few posts on where you should start here:

But, if you really want the condensed version, Bart de Smet has a really nice introduction on functional programming in a series, although incomplete, which you can read here:

Now that I take it you have read that and caught up, let's continue onto today's part.

The Joys of Currying

Where we left off last time was just dealing with the basics of functions and the fact that they are treated as values much like any other "variable". Now let's get into a popular topic among functional programming, a concept called Currying. The term was invented back in the earlier days of functional programming after the early logician Haskell Curry. He's so good in fact that he got not only a functional programming style named after him, but a language named after him with Haskell. If you listen to the DotNetRocks Episode 310 with Simon Peyton-Jones, you can learn more about that.

Anyhow, the basic idea of Currying is to take a function with multiple arguments and transform it into a function that passes in only one argument, with the other arguments specified in the Currying function itself. So you can think of it as a function that calls another function and returns a function. You can think of it also as being a partial function. So, let's actually get down to it and write some F# code to show how to do this:

#light

let n = 10

let multiply a b = a * b

let multiplyByFive = multiply 5

let result = multiplyByFive 4

printfn "result = %i" result

So, what I accomplished above is that I had a function called multiply that takes two arguments, a and b. Then I created a currying function called multiplyByFive which curries the multiply function by supplying a five value. Then I can call the multiplyByFive curried function with a 4 and sure enough the result is 20.

As always, I'm always curious on how it looks through .NET Reflector to see how F# does its magic. So, let's crack that open and take a look. First let's look at the tree of Reflector to see what it creates for us:

Now as you can see, it created the multiply function. Then we also have a multiplyByFive FastFunc function. The functions get stored in the namespace free area and yet the main function gets placed elsewhere. Now, let's look at the function implementation itself.

From what you can see, it created a SampleFile class because I created a SampleFile.fs to create the curried functions.

For those of you who are C# buffs, well, you can also do the same in C# with the new anonymous function type, System.Func in .NET 3.5. Mads Torgersen, the C# Program Manager, noted on his blog quite a while ago asking the question, "Is C# Becoming a Functional Language?". This post was pretty great and it's unfortunate that he doesn't blog as much as he does. Remember kids, this isn't as pretty as F# because it's not what C# is really good at, but slowly but surely, functional programming paradigms are slowly seeping into C#.

namespace CSharpCurriedFunctions
{
    public static class CurriedFunctionExtensions
    {
        public static Func<A, Func<B, R>> Curry<A, B, R>(this Func<A, B, R> f)
        {
            return a => b => f(a, b);
        }

    }

    class Program
    {
        static void Main(string[] args)
        {
            Func<int, int, int> multiply = (a, b)=> a* b;
            Func<int, Func<int, int>> curriedMultiply = multiply.Curry();
            Func<int, int> multiplyByFive = curriedMultiply(5);

            Console.WriteLine("result = {0}", multiplyByFive(4));
        }
    }
}

If you're interested more in doing this with C#, I would suggest you head over to Dustin Campbell's blog and read the post about The Art of Currying. For those who want to learn more, well, Dustin should be at ALT.NET Open Spaces, Seattle and hopefully will submit an F# topic for us to get our heads around.

How useful is this in C#? Well, time will tell, but you could imagine having some search criteria for your repository using curried functions to "overload" with values. Anything is really possible, but as you can see, it's a lot cleaner in F# and that's where it really shines.

The Odd Tuple

When specifying arguments to any given function, you can specify them without parentheses much as you would in VB.NET should it be a subroutine. This is really helpful if you want to enable currying and such. But, you can also specify them as a tuple. For the math illiterate among you, that simply means a sequence of objects of a specified type. This you must put within parentheses. This makes you supply all arguments at once. A simple example of this would look like this:

#light

let add (a, b) = a + b

let result = add(3, 4)

printfn "result = %i" result

Pretty simple example and of course the result would be 7.

Where is the Returns Department?

As you may have noticed from the functions from above, I never really did specify any return type or return statement. Implicitly behind the scenes, F# does that for you. Basically when you define a function, you should indent with a tab and the last assignment becomes your return value. The return is implicit right after the indenting is ended. So, let's take a simplistic view of this:

#light

let addThings a b =
let c = a + b
sprintf "result = %i" c

let result = addThings 3 7

print_string result

As you may notice, when using the light syntax (#light), you cannot indent, instead just use two spaces and that should suffice. Anyhow, you may note, I was doing a simple addition and then my final assignment becomes my return value, which is using the sprintf function, which to you C buffs out there, should look familiar.

Conclusion

I've got a lot more on this topic quite frankly and still just covering the basics of your first F# program. There is so much to learn on this, but these are the basic building blocks you need to make that leap into functional programming. It's becoming more interesting year by year as our languages such as Ruby, C# and so on continue to drive towards functional programming, so it's important to grok the fundamentals. Next time, I hope to cover some recursion stuff, functions, lists and even operators (the really fun stuff). Until next time...