class abstract CommonLogic
{
    protected CommonLogic(IFirstLowLevelService firstService) {}
}

…that several developers wanted to subclass. They all believed in the inversion of control principle and took therefore all their dependencies as constructor parameters.  With Autofac, a dependency injection framework at hand they ventured forth implementing many great subclasses. Some of these appeared like this:

class SpecificLogic : CommonLogic
{
    public SpecificLogic(
        IHighLevelService highLevelService,
        IFirstLowLevelService firstService)
    : base(firstService) {}
}

All was well and the number of variations of special logic classes grew and prospered.

Until one day a Senior Developer wanted to extend the base class with new logic requiring more dependencies. Now all the subclasses had to include the new dependencies in their constructors too, passing them on to the base class.

class abstract CommonLogic
{
    protected CommonLogic(
        IFirstLowLevelService firstService,
        ISecondLowLevelService secondService,
        IThirdLowLevelService thirdService
        ) {}
}

class SpecificLogic : CommonLogic
{
    public SpecificLogic(
        IHighLevelService highLevelService,
        IFirstLowLevelService firstService
        ISecondLowLevelService secondService,
        IThirdLowLevelService thirdService)
    : base(firstService, secondService, thirdService) {}
}

The changes caused great disturbance throughout the Source Repository, affecting both production code and test code alike, delaying schedules and disheartening the developers.

Then a brave developer set out on a quest to free the Source from darkness. And he found the Aggregate Service, a pattern that promised to isolate the subclasses from future changes in the base class constructor:

class abstract CommonLogic
{
    public interface IAggregateService
    {
        IFirstLowLevelService FirstService {get;}
        ISecondLowLevelService SecondService {get;}
        IThirdLowLevelService ThirdService {get;}
    }

    protected CommonLogic(IAggregateService aggregateService) {}
}

class SpecificLogic : CommonLogic
{
    public SpecificLogic(
        IHighLevelService highLevelService,
        IAggregateService aggregateService)
    : base(aggregateService) {}
}

Furthermore, by tapping into the power of Castle DynamicProxy2, the developer crafted a device that could dynamically generate aggregate services, completely removing the burden of implementing classes for each aggregate service interface.

Finally, the valiant adventurer approached the Senior Developer and presented the pattern and how it could free them from distress merely by aggregating constructor-injected dependencies into one dependency. Seeing its brilliance, the aggregate service pattern was implemented throughout the Source spreading light and joy to the team. Changes could now be made to the base class dependencies by merely changing the IAggregateService interface, and no change would have to be done to the subclasses ever again.

So great was the joy and relief that the Senior Developer declared:

The Aggregate Service belongs to all developers of the land and shall thus be contributed to Autofac.

Factories are useful when you need fine-grained control over when dependencies should be resolved. Also, if you have dependencies that requires data input (e.g. a constructor parameter) and you need some way of passing that data into the dependency, a factory is your friend.

With Autofac it gets even better. Using C# I can declare a delegate that represents the signature of such a factory, register the delegate in my container and voila! Autofac generates the implementation based on the signature.

So I could declare a delegate like this:

public delegate ICustomerService CustomerServiceFactory();

and have it injected in, say, one of my controller classes, like this:

public class CustomerController
{
    private CustomerServiceFactory _customerServiceFactory;
    public CustomerController(CustomerServiceFactory customerServiceFactory)
    {
        _customerServiceFactory = customerServiceFactory;
    }
}

My controller now have the ability to decide when to create the service instance and still not need to know how.

To make the sample complete (thus far) I’ll show how the Autofac container setup looks like at this point:

var builder = new ContainerBuilder();
builder.Register<CustomerService>();
builder.RegisterGeneratedFactory<CustomerServiceFactory>();
builder.Register<CustomerController>();

This works great. And was fairly easy too don’t think? Now imagine that these classes and delegates was a small part of a real system, with hundreds of controllers and services. Having to declare a factory delegate for each service becomes a pain, let aside registering them in the container.

Wouldn’t it be nice if we could declare only one factory that could build all service types? Turns out you can. Think about the following generic delegate:

public delegate T ServiceFactory<T>() where T:class;

Our updated controller dependency now looks like this:

public class CustomerController
{
    private ServiceFactory<CustomerService> _customerServiceFactory;
    public CustomerController
        (ServiceFactory<CustomerService> customerServiceFactory)
    {
        _customerServiceFactory = customerServiceFactory;
    }
}

Registering such a delegate in the container becomes a bit tricky, since we don’t know T at registration time. Even more so, we cannot generate the factory delegate at registration time! The solution is to register the open generic type coupled with a method that will generate the factory when the dependency is asked for. The Autofac setup should now look like this:

var builder = new ContainerBuilder();
builder.Register<CustomerService>().As();
builder
  .RegisterGeneratedFactoryFromOpenType(typeof(ServiceFactory<>));
builder.Register<CustomerController>();

The RegisterGeneratedFactoryFromOpenType extension method does two things:

1. Register the open generic type using builder.RegisterGeneric
2. Attach factory generation code to the OnPreparing event.

The OnPreparing event will be fired when Autofac tries to resolve a closed version of the delegate, in our case the ServiceFactory delegate. Since the event argument contains this type we have everything necessary for generating the factory implementation. And here’s the implementation of RegisterGeneratedFactoryFromOpenType:

public static IGenericRegistrar
    RegisterGeneratedFactoryFromOpenType
    (this ContainerBuilder builder, Type openFactoryType)
{
    return builder.RegisterGeneric(openFactoryType)
        .OnPreparing(Prepare);
}

static void Prepare(object sender, PreparingEventArgs args)
{
    var factoryType = args.Component
        .Descriptor.BestKnownImplementationType;
    var serviceType = factoryType
        .GetMethod("Invoke").ReturnType; 

    var service = new TypedService(serviceType);
    var factory = new FactoryGenerator(factoryType, service); 

    args.Instance = factory
        .GenerateFactory(args.Context, args.Parameters);
}

Note: this code is based on the latest release of Autofac 1.

Prerequisites

We need the Custom Field plugin by FogCreek and BugMonkey by Michael Pryor. If you’re a FogBugz on Demand user these are readily available in the Plugins admin panel.

Adding a custom field

Next, configure the Custom Field plugin and add a number field named “Wiki Page” with the description “Related wiki page”. Make a note of the description since it will come in handy later.

You will now have an extra field on each case called Wiki Page in which we expect users to enter the page id of a related wiki.

Making the field a link to the wiki page

Now go and configure the BugMonkey plugin. This plugin enables javascript to be executed on every page in your FogBugz installation. Luckily, the FogCreek team have already added JQuery into FogBugz mix so we can ride on that. Add the following script in the javascript text area:

var wikiPage = $(“.content[title='Related wiki page']“);
wikiPage.html(“<a href=”/?W + wikiPage.text() + “>Related wiki page</a>”);

The content of the wiki page field is rendered as a div element with class “content” and a title containing the field description. Thus, using JQuery to look up the element is a breeze.

After grabbing the element it is straightforward to add an anchor pointing to the wiki page url.

Conclusion

Ideally I would love to see the Custom Field plugin add the field name to the html element, perhaps as and id. Apart from that, with a plugin system and an eager developer community, systems like FogBugz can really reach new levels of extendability without having to put all possible features into the product up front.

Thumbs up for a great product, Fog Creek!

In the early stone age we had to make do with multiple computers to achieve such isolated environments. Then came the advent of emulators and virtual computers. For many years now we have had virtualization solutions that run virtualized computers, but with a performance cost in both resource consumption and processing speed. Mind you, the performance keeps improving with better hardware support.

With Windows 7 however, a hybrid solution is introduced. By virtualizing only the disk subsystem, Windows 7 is able to boot from a file system that is completely contained within a Virtual Hard Drive file, or VHD. The end result is that OS and applications execute on “the bare metal” while a thin virtualization layer redirects disk IO to the VHD file residing on the bare-metal disk.

Guest author Thomas Sandberg gives a quick rundown on how to set up booting from Virtual Hard Drives with Windows 7. Read the article here!

Hang on, I’m getting there.

Below is a map extract that shows part of my route. The topmost pin is where I start out, the bottom-most pin is the Oslofjord tunnel. The pin in the middle is where, more often than not, a sign shows up stating that the tunnel is closed for maintenance.  You can imagine my frustration when I’m forced to drive all the way back north to get around the Oslofjord!

To avoid that pain I set out to find a feed with traffic status updates and ended up at this page published by the Norwegian Public Roads Administration (NPRA). The page have regularly updated traffic information (all in Norwegian mind you) but to my frustration all as static web pages. No feed in sight!

At last here comes the screen scraping into play. You could write up your own scraper in any modern runtime these days. But being a good/lazy developer I know there are already quite good services out there that makes it a breeze setting up feeds with data scraped off of web pages. And lo and behold, I now burn a feed with the latest traffic updates!

So… basking in the glory of my genius for a couple of days I thought it a good idea to write up this blog post for the greater good of mankind. To make the story a bit shorter, what I discovered while rummaging around the NPRA site is that they indeed have great support for RSS!

Feeling a bit stupid I will now go and redirect my FeedBurner setup…and please let me know if there is a moral to this story.

Good night.

Now, for those of us that didn’t realize the value of services like FeedBurner when setting up a new blog, I will highlight one advantage that I wish I knew when I started out blogging. Namely that exposing my feed via FeedBurner will save my faithful subscribers from having to update their subscription when the blog will have to move.

The feed address is hereby  http://feeds.feedburner.com/PetersPattern. I can promise you that this link will not change. That is, unless Google goes out of business