CODEWITHSUNDEEP
asp.net-mvcninjectninject.web.mvc
Grofit
Grofit

Reputation: 18445

Ninject binding/unbind issue

I have a bit of a dilemma, which to be honest is a fringe case but still poses an issue.

Currently I am using Ninject MVC and bind all my controllers like so:

Kernel.Bind<SomeController>.ToSelf();

Which works a treat for 99% of things that I have needed to do, however at the moment I am doing some wacky stuff around dynamic routing and dynamic controllers which require me to manually write a method to get the type of a controller from ninject. Now initially I thought it would be easy, but its not... I was expecting that I could get the controller based on its name, but that didnt work.

Kernel.Get<IController>("SomeController");

That got me thinking that its probably because it only knows about a binding to SomeController, not IController. So I thought, I can just write all my bindings like so:

Kernel.Bind<IController>.To<SomeController>().Named("SomeController");

This way it should be easy to get the type of the controller from the name doing the previous code, however if I were to bind this way, I would have a problem when I come to unbind the controllers (as plugins can be loaded and unloaded at runtime). So the normal:

Kernel.Unbind<SomeController>()

Which was great, will no longer work, and I would have to do:

Kernel.Unbind<IController>();

However then I realised that I need to give it some constraint to tell it which binding for this type I want to unbind, and there seems to be no overloads or DSL available to do this...

So I am trapped between a rock and a hard place, as I need to satisfy the ControllerLookup method, but also need to keep it so I can add and remove bindings easily at runtime.

protected override Type GetControllerType(RequestContext requestContext, string controllerName) { 
//... find and return type from ninject
}

Anyone have any ideas?

(Just incase anyone questions why I am doing this, its because of the way I am loading plugins, Ninject knows about the types and the namespaces, but within the context of creating a controller it doesn't know the namespace just the controller name, so I do this to satisfy the isolation of the plugin, and the location of the dynamic controller, it is a roundabout way of doing it, but it is what people have done with AutoFac before Example of similar thing with AutoFac)

Upvotes: 1

Views: 2121

Answers (1)

Remo Gloor
Remo Gloor

Reputation: 32725

In my opinion the bindings should be created once at application startup and not change anymore after the first resolve. Everything else can lead to strange issues. Unless you have proper isolation using an AppDomain for each plugin you can not really unload them anyway. Instead of unloading bindings you can make them conditional and disable them using some configuration.

If you really want to unload bindings then I suggest not to do it for single bindings but take advantage of modules. Load all bindings belonging to one plugin together in one or several modules and unload those modules instead of the single bindings.

Upvotes: 3

Related Questions