In the last article I touched on how IoC is used within botframework using Autofac.

If you’re comfortable with IoC, you probably started to enhance your dialogs using constructor injection, so that you can put your conversation logic outside of your entry point and just start coding without needing an implementation to exist yet, e.g.,

[Serializable]
public class ResolvingDialog : IDialog<object>
{
    private readonly IMessageRepository _messageRepository;

    public ResolvingDialog(IMessageRepository messageRepository)
    {
        _messageRepository = messageRepository;
    }

    public async Task StartAsync(IDialogContext context)
    {
        await context.PostAsync($"Hi!");
        context.Wait(MessageReceivedAsync);
    }

    public async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> argument)
    {
        var message = await argument;
        await _messageRepository.SaveMessage(message);

        await context.PostAsync($"working now");
        context.Wait(MessageReceivedAsync);
    }
}

Then you can just wire up the interface resolution by defining the default implementation for the interface in your IoC configuration e.g.

var builder = new ContainerBuilder();
builder.RegisterType<MessageRepository>().As<IMessageRepository>();

...

var container = builder.Build();

Easy, right? Exactly how you’d do it for a Controller in a WebAPI or MVC project.

However..

Ah. This appears to be due to the dialog and all their dependencies needing to be serialized such that the conversation can avoid needing “sticky sessions” to keep the context between messages.

ye olde service locator pattern

One way to avoid this that I’ve been using is something like a Service Locator/Factory pattern.

Yes, people don’t like the Service Locator pattern, so if you’re one of them please do suggest alternative solutions! I’d love to hear them.

Instead of using constructor injection, we can define a static property on the dialog which is resolved via a factory class to retrieve the concrete implementation via our IoC configuration.

Lots of long words there, so let’s look at some code instead!

The dialog now has a property for each interface we need an implementation for, resolved using another class:

[Serializable]
public class ResolvingDialog : IDialog<object>
{
    private static readonly IMessageRepository _messageRepository
       = ServiceResolver.Get<IMessageRepository>();

    public async Task StartAsync(IDialogContext context)
    {
        await context.PostAsync($"Hi!");
        context.Wait(MessageReceivedAsync);
    }

    public async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> argument)
    {
        var message = await argument;
        await _messageRepository.SaveMessage(message);

        await context.PostAsync($"working now");
        context.Wait(MessageReceivedAsync);
    }
}

That ServiceResolver class merely hooks into AutoFac and returns a concrete implementation:

public static class ServiceResolver
{
    public static IContainer Container;

    public static T Get<T>()
    {
        using (var scope = Container.BeginLifetimeScope())
            return scope.Resolve<T>();
    }
}

Now we just set the resolver’s static Container in a bootstrapping class (or just in the Global.asax.cs):

var builder = new ContainerBuilder();
builder.RegisterType<MessageRepository>().As<IMessageRepository>();
...
var container = builder.Build();

ServiceResolver.Container = container;

Now running that again gives us:

static?! Service Locator?!

Yeah, the service resolution class is static. The properties in the dialog are static. I’m using a Service Locator pattern.

This may not seem clean, but it means these dependencies do not need to be [Serializable]. Having a Container property on ServiceResolver means we can pass in a container full of mocks/ stubs/ fakes/ substitutes to facilitate testing whilst using this static class.

Summary

We’ve now got a way of keeping the dialog classes reasonably empty, merely handling initial routing like a Controller would.

This should hopefully allow for a nicer structure in your bot code. I’d be interested in hearing how you’ve solved this problem in your own projects, since – let’s face it – I’m using a Service Locator and static all over the place..