Simple Injector per-web-api-request dependency in SignalR hub

Question

According to this post, it should be possible to inject per-web-request dependencies into SignalR hubs (although with some limitations like problem with OnDisconnected() met

Answer 1

Recently I faced the same problem and found the following working quite well, hope this will help someone:

public class SignalRDependencyResolver : DefaultDependencyResolver
{
    public SignalRDependencyResolver(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public override object GetService(Type serviceType)
    {
        return _serviceProvider.GetService(serviceType) ?? base.GetService(serviceType);
    }

    public override IEnumerable<object> GetServices(Type serviceType)
    {
        var @this = (IEnumerable<object>) _serviceProvider.GetService(typeof (IEnumerable<>).MakeGenericType(serviceType));

        var @base = base.GetServices(serviceType);

        return @this == null ? @base : @base == null ? @this : @this.Concat(@base);
    }

    private readonly IServiceProvider _serviceProvider;
}

public class SignalRHubDispatcher : HubDispatcher
{
    public SignalRHubDispatcher(Container container, HubConfiguration configuration) : base(configuration)
    {
        _container = container;
    }

    protected override Task OnConnected(IRequest request, string connectionId)
    {
        return Invoke(() => base.OnConnected(request, connectionId));
    }

    protected override Task OnReceived(IRequest request, string connectionId, string data)
    {
        return Invoke(() => base.OnReceived(request, connectionId, data));
    }

    protected override Task OnDisconnected(IRequest request, string connectionId, bool stopCalled)
    {
        return Invoke(() => base.OnDisconnected(request, connectionId, stopCalled));
    }

    protected override Task OnReconnected(IRequest request, string connectionId)
    {
        return Invoke(() => base.OnReconnected(request, connectionId));
    }

    private async Task Invoke(Func<Task> method)
    {
        using (_container.BeginExecutionContextScope())
            await method();
    }

    private readonly Container _container;
}

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var container = new Container();

        container.Options.DefaultScopedLifestyle = new ExecutionContextScopeLifestyle();

        container.Register<DbContext, MyDbContext>(Lifestyle.Scoped);
        container.Register<ISampleRepository, SampleRepository>(Lifestyle.Scoped);

        // if you want to use the same container in WebApi don't forget to add
        app.Use(async (context, next) => {
            using (container.BeginExecutionContextScope())
                await next();
        });

        // ... configure web api 

        var config = new HubConfiguration
        {
            Resolver = new SignalRDependencyResolver(container)
        }

        // ... configure the rest of SignalR

        // pass SignalRHubDispatcher
        app.MapSignalR<SignalRHubDispatcher>("/signalr", config);
    }
}

Answer 2

Your definition of your hybrid lifestyle is incorrect. The WebApiRequestLifestyle does not depend in any way on the HttpContext so checking whether HttpContext.Current != null will not work. You will have to check if there is an active Web API request lifestyle scope (or execution context scope, which is basically the same) by calling container.GetCurrentExecutionContextScope():

var transientHybrid = Lifestyle.CreateHybrid(
    () => container.GetCurrentExecutionContextScope() != null, 
    new WebApiRequestLifestyle(), 
    Lifestyle.Transient);

Do note however that you should be very careful composing a hybrid lifestyle of a scoped lifestyle and transient, because this will easily yield in wrong results. This is actually the default behavior of some DI libraries, but this is a design flaw IMO. I assume you very consciously registered your MyDbContext with the scoped lifestyle, because you need to make sure that the same instance is used throughout the request. Using the Transient lifestyle means that you might get multiple MyDbContext during the request. This might not be a problem, because in your hubs you might currently only have one reference to your MyDbContext, but your code might break once your object graph changes and a second reference to MyDbContext is added.

So instead, I would advice not using this combination of lifestyles. Instead, just use either the WebApiRequestLifestyle or the ExecutionContextScopeLifestyle (they are the same) and make sure that such a execution context scope is started before your hub is resolved.

And by the way, don't forget to register your hubs explicitly in Simple Injector. This allows Simple Injector to analyze the complete object graph for you including your hub classes.