In the past week or so I have been trying to come to grips with Windows Workflow Foundation (WF).  I have read numerous articles (the good ones are few and far between) and I think I’m finally getting the hang of it.  To this end I’m going to create a Bug-tracking application as an example of creating a workflow-based website.

This entire idea is based on two excellent articles by Scott Allen.  The first is a Bug-tracking workflow (yes, that’s where I got the idea) and the second is an Order-tracking workflow.  I’m going to combine ideas from both of these and try and create a web-based Bug-Tracking application using Asp.Net MVC.  Along the way I’m going to introduce dependency injection using Unity and also use a service layer as well as the repository pattern.

Step 1 – Using Unity with Asp.NET MVC

I’m not the greatest fan of dependency injection frameworks – I prefer using ‘poor man’s dependency injection’ – provide constructor overloads for dependency injection (during testing) and simply new the concrete implementation in the default constructor.  However for this application I found it extremely useful – there are various singleton objects that you need to pass around and Unity does that pretty nicely.

To get started, add a reference to Microsoft.Practices.Unity and Microsoft.Practices.ObjectBuilder2.  You have 2 choices for configuring Unity – in code or with an xml config file.  I went the code route.

I create a static class called Bootstrapper inside my web project – this contains all the logic for configuring Unity.  We need to call this class from our Application_Start event.

protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    Bootstrapper.ConfigureUnityContainer();
}

So far so good.  Now we simply create the Unity container and map interfaces to concrete implementations.

var container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);

// Services
container.RegisterType<IBugService, BugService>();
container.RegisterType<IUserService, UserService>();

// Repositories
container.RegisterType<IUserRepository, UserRepository>();
container.RegisterType<IBugRepository, BugRepository>();

Registering the container with itself is a pretty neat trick – this allows us to use the actual container as a dependency down the line.  Now that we’ve configured the container we need to use it by using Unity to create all our Controllers.  To do this we need to create a ControllerFactory.

public class ControllerFactory : DefaultControllerFactory
{
    private readonly IUnityContainer container;

    public ControllerFactory(IUnityContainer container)
    {
        this.container = container;
    }

    protected override IController GetControllerInstance(Type controllerType)
    {
        if (controllerType == null)
        {
            return null;
        }
        else
        {
            return (IController)container.Resolve(controllerType);
        }
    }
}

The last step is to register this factory with MVC – we do this from inside the Bootstrapper.

ControllerBuilder.Current.SetControllerFactory(new ControllerFactory(container));

In my next post I’m going to design the workflow and show how to integrate the domain objects with workflow persistence.  I will publish all the code at the end of this series.

Share on: Twitter, Facebook, Google+ or use the Permalink