Dependency injection

Parallel executed Tasks with isolated scopes

My current customers infrastructure is heavily dependent on external suppliers of data. Because of the nature of the data the system often have to-do the requests in real time while the end-customer is waiting for the response. Parallel tasks comes in handy when you want to aggregate data from several end points, both because it puts less strain on the Thread Pool and that your response time will be faster because you do not need to wait for each to complete (Parallel vs Sequential).

The problem starts with frameworks that does not play nice with sharing their resources over multiple Tasks/Threads, an example of this is the Entity Framework DbContext. One way is to marshall the lifetime of the context yourself and spawn one for each parallel task. But this is not a solid design, if you use a IOC you want any object in the current graph to receive the same instance of the DbContext without bothering with lifetime code. I created a little class called TaskRunner for this purpose (more…)

Abstract DI container Scopes

I saw an increasing demand for mini workflows / domain sub-parts in one of my projects. Most containers have some kind of support for sub scopes or nested containers, but I do not want to expose the Container API. If you have few places were you need nested containers you can implement this directly for your container of choice. An example of this is a container specific implementation of Web API’s IDependencyResolver. But in our case we had several different needs for scoped contexts near the domain. My solution was to abstract the context in a interface IScopedContext. (more…)

Why overriding JsonSerializer no longer work in SignalR 2.0

I see almost everyday people having problem with overriding JSON serializer settings in SignalR. In SignalR 1.x they used an interface, IJsonSerializer, that you could override to set the JSON settings. In SignalR 2.x they instead use a concrete type JsonSerializer.

Ninject

The problem starts if you use a dependency injection framework like Ninject. The Dependency resolver that most people use for Ninject together with SignalR is doing this to get a type.

return kernel.TryGet(serviceType) ?? base.GetService(serviceType);

In SignalR 1.x this worked because when Ninject is doing TryGet on an interface it will return null and instead call base.GetService which in turn will use the type registered with SignalR’s internal IoC (GlobalHost.DependencyResolver).

In SignalR 2.x this will no longer work because we are now using a concrete type and Ninject will create instances of unregistered concrete types without complaining. base.GetService will never be called and the types registered in GlobalHost.DependencyResolver will not be used.

Remedy

One way of solving this is to register the JsonSerializer with the Ninject kernel instead of register it with GlobalHost.DependencyResolver.Register

The other is to check if the type is registered with Ninject, if it is use kernel.Get otherwise use base.GetService. This can be done like

kernel.GetBindings(serviceType).Any();