Question

We have an ASP.NET Web API app which uses Ninject for DI. This works perfect for use. One of the improvements we were considering is the ability to swap out parts of functionality per request based on some sort of unique identifier.

Example. Two customers use our restful api. Both get the same functionality. A third customer has paid for the super version of our api. He makes the request, we load the super dll and bind the super implementations to the standard interfaces.

Essentially what I am looking to see is can we load a DLL and swap out bindings per request using Web API and Ninject.

EDIT:

So both answers are correct for the original question but my intention is different and it is my fault for not explaining it correctly. What we have is a base layer of functionality that everyone gets. On top of this we also have the ability to implement custom logic on a per customer basis that overrides this functionality. This logic is stored as a DLL in Azure Blob Storage.

What we would like to do is when a customer makes a request is go get the DLL, bind all the custom services and then service the request using these new bindings.

Is hot swapping not the best way to do this? We are new enough to ninject so this may be a common thing that is implemented in a different way to what we are considering.

To some up, we would like to be able to service custom bindings on a per customer basis.

EDIT 2:

We use conditional bindings for items were we know that we have alternate implementations but in the scenario above until we get the customer info and scan the dll we do not know if we have alternate bindings. We don’t even know if there is a dll.

We would like to do it this way so we can drop the file in rather than referencing it in the project.

Answer 1

I don’t mind that you can swap out bindings per request. But what you can do is to use conditional binding.

Example – default bindings:

protected override Ninject.IKernel CreateKernel()
{
    var kernel = new StandardKernel();

    kernel.Bind<IAuthorizationService>()
        .To<AuthorizationService>()
        .InRequestScope();

    kernel.Bind<IService>()
        .To<BasicService>();

    return kernel;
}

It will inject (on place where IService is needed) a BasicService for some basic user and ExtraService for VIP user.

For more information about various ways of conditional binding see Ninject – Contextual binding.

EDIT

I think you can still use conditional binding. You will only need to propagate the IKernel to place where you want to register components from new dll. For example I have this in my global.asax for dynamically loading dll modules – it runs on app startup.

Loading modules:

private void LoadAssemblies(IKernel kernel) {
    foreach (var fileName in Directory.GetFiles(Server.MapPath("~/App_Data"), "*.dll")) {
        Assembly loadedAssembly = Assembly.LoadFile(fileName);
        try {
            var moduleRegistrations = loadedAssembly.GetTypes()
                .Where(t => t.IsClass && t.IsAbstract == false && typeof (IMyModuleRegistration).IsAssignableFrom(t));

            foreach (var moduleRegType in moduleRegistrations ) {
                IMyModuleRegistration moduleReg = (IMyModuleRegistration) Activator.CreateInstance(moduleRegType);
                moduleReg.RegisterComponents(kernel);
            }
        }
        catch (ReflectionTypeLoadException exception) {
            ....
        }
    }
}

Module definition:

public class MyExtraModule : IMyModuleRegistration
{
     public void RegisterComponents(IKernel kernel)
     {
         kernel.Bind<IService>()
               .To<ExtraService>()
               .When(x => x.ParentContext
                           .Kernel.Get<IAuthorizationService>()
                           .IsVIPUser());
     }
}

ExtraService will be used only when dll with MyExtraModule is loaded.

EDIT 2

You can download that dll from somewhere. Load it and then test it if it implements your registration interface. Then call that registration and you are done. The only problem I see is: where to store the reference to IKernel – probably some static property in HttpApplication will be enough. You should also track already loaded dlls.

Or in later versions of Ninject I can suggest extending the NinjectModule and then load it into kernel with kernel.Load(..) method. Look at this Modules and kernel – specially in part Dynamic Module Loading – maybe it is what you are looking for.