I’ve covered my SignalR Event aggregation library in an earlier post found here. That library has a Constraint API so that you can control which events a specific user should receive. It requires you to write one constraint handler for each type of event. But how about standard declarative Role Authorization?
(more…)
SignalR 2.0
Client – server event aggregation with SignalR
Event aggregation is really a pattern i like, there is something elegant about firing events and subscribers can listen to them without knowing who fired them. This creates decoupled domains both in backends and frontends. At my latest customer we saw an increasing demand for pub / sub and immediate update. We fired events on the backend event bus and in the frontend we had SignalR Hubs that picked up the events and forwarded them to the clients. This caused duplicated and similar code both on the client and on the web server. I decided to create an abstraction layer between SignalR and the event aggregator. The result is a library called SignalR.EventAggregatorProxy
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();
Anders Malmgren 