Pass a dependency instance to a factory method parameter to make Ninject use it within the resolution

Question

I have an abstract factory which creates some service represented by IService interface. In the factory I have two Create methods, because at one of them I allow the consumer to pass an existing IServiceLogger instance to be used by the constructed service tree.

public interface IMyServiceFactory {
  IMyService Create(IServiceLogger loggerInstance);
  IMyService Create();
}

Because an IServiceLogger should be shared among the service tree, I use the InCallScope when binding it to a concrete implementation.

How can I implement this scenario with Ninject? I've tried the following approaches.

1. Manually create a factory implementation

internal class MyServiceFactory : IMyServiceFactory {

  private IResolutionRoot _kernel;

  public MyServiceFactory  

  public IMyService Create(IServiceLogger loggerInstance) {
    // what should go here? how can I pass the existing instance to Ninject Get method and make Ninject to use it for the whole resolution tree, just as it were created by Ninject and used as InCallScope?
  }

  // this one is trivial...
  pulbic IMyService Create() {
    return _kernel.Get<IMyService>();
  }
}  

UPDATE

Actually I've found a messy and not too safe way for this. I can get the current bindings via GetBindings, then Rebind IServiceLogger ToConstant, then Get the IMyService instance, and finally restore the original bindings with AddBinding. I don't like it, it feels stinky and what's worse, it's not thread-safe, because another thread can request for a IMyService in the middle of this code and hence use the local temporary binding.

2. Use Ninject.Extensions.Factory

Just use the ToFactory binding, but that's not working, because it just tries to use the parameter as a simple constructor argument (if applicable), and not as an object for the whole resolution tree.

Answer 1

I would give more control to the Kernel of Ninject and do not create a class for the factory at all. And use Func binding in Ninject like this:

Bind<Func<IMyService>>().ToMethod(s => CreateService);

By binding of the ILoggerService or not binding this you can controll centrally whether you have logger or not in your service.(try by just comment it out)

Here implementation of the Bootstrapper:

 public class Bootstrapper
    {
        private IKernel _kernel = new StandardKernel();

        public Bootstrapper()
        {
            _kernel.Bind<MyStuff>().ToSelf();
            _kernel.Bind<IServiceLogger>().To<ServiceLogger>();
            _kernel.Bind<IMyService>().To<MyService>();

            _kernel.Bind<Func<IMyService>>().ToMethod(s => CreateService);
        }

        public IKernel Kernel
        {
            get
            {
                return _kernel;
            }
            set
            {
                _kernel = value;
            }
        }

        private IMyService CreateService()
        {


            if(_kernel.GetBindings(typeof(IServiceLogger)).Any())
            {
                return _kernel.Get<IMyService>(new ConstructorArgument("logger", _kernel.Get<IServiceLogger>()));
            }

            return _kernel.Get<IMyService>();
        }
    }

Implementation of consumer class for the factory:

 internal class MyStuff
    {
        private readonly Func<IMyService> _myServiceFactory;

        public MyStuff(Func<IMyService> myServiceFactory)
        {
            _myServiceFactory = myServiceFactory;

            _myServiceFactory.Invoke();
        }
    } 

Simple implementation of MyService:

 internal class MyService
        :IMyService
    {
        public MyService()
        {
            Console.WriteLine("with no parameters");
        }

        public MyService(IServiceLogger logger)
        {
            Console.WriteLine("with logger parameters");
        }
    }

Simple ServiceLogger:

internal class ServiceLogger
        :IServiceLogger
    {
        public ServiceLogger()
        {

        }
    }

    internal interface IServiceLogger
    {
    }

Answer 2

IMPORTANT UPDATE

While my original answer gave me a working solution, by an accidental InteliSense navigation I've just found that there is a built-in tool for exactly this issue. I just have to use the built-in TypeMatchingArgumentInheritanceInstanceProvider which does this, and even more, because there are no more needs for naming conventions due to the parameter type matching.

It would be good to have a more detailed documentation about these options, or maybe it's just me who can't find it currently.

---

ORIGINAL ANSWER

I tried a few ways, and ended up with a slightly different, kind of a convention based approach utilizing Ninject's context parameter inheritance.

The convention is used at constructor argument naming through the dependency tree. For example whenever an IServiceLogger instance is injected to a service class, the argument should be called serviceLogger.

With the above convention in mind, I've tested the following approach. Firstly I've implemented a custom instance provider for the factory extension. This custom provider overrides the mechanism for creating constructor parameters for the context to let the developer specify several named arguments which should be set as inherited. This way all the parameters with the specified names will inherit through the whole request graph during the get operation.

public class ParameterInheritingInstanceProvider : StandardInstanceProvider
{
    private readonly List<string> _parametersToInherit = new List<string>();

    public ParameterInheritingInstanceProvider(params string[] parametersToInherit)
    {
        _parametersToInherit.AddRange(parametersToInherit);
    }

    protected override IConstructorArgument[] GetConstructorArguments(MethodInfo methodInfo, object[] arguments)
    {
        var parameters = methodInfo.GetParameters();
        var constructorArgumentArray = new IConstructorArgument[parameters.Length];
        for (var i = 0; i < parameters.Length; ++i)
            constructorArgumentArray[i] = new ConstructorArgument(parameters[i].Name, arguments[i], _parametersToInherit.Contains(parameters[i].Name));
        return constructorArgumentArray;
    }
}

Then after at binding configuration I just threw it in with the corresponding parameter name.

kernel.Bind<IMyServiceFactory>().ToFactory(() => new ParameterInheritingInstanceProvider("serviceLogger"));

Finally I reviewed parameter naming, and for exampled changed loggerInstance in the factory interface to serviceLogger to match the convention.

This solution is still not the nicest one as it has several limitations.

1. It is error prone. One can make bugs which are hard to track by not keeping the naming convention, because currently it silently fails if the convention does not match. This could be improved probably, I'll think about it later.
2. It handles only constructor injection, however this should not be a big issue as that's the suggested technique. For example I almost never do other kind of injections.

Answer 3

I realise this was asked a long time ago but I was looking to do the same sort of thing myself and finally worked out that you can use the IParameter array passed to the Get() method to specify a ContructorArgument to use only for the current Get() call. This allowed me to use a specific constructor value when creating a Hangfire Job allowing the Hangfire job to use a different database connection on each invocation if required.

                    EnvironmentName forcedEnv = new EnvironmentName() { Name = dbName };

                    // For this instantiation, set the 'envName' parameter to be the one we've specified for this job
                    var instance = ResolutionExtensions.Get((IResolutionRoot) _kernel, jobType, 
                        new IParameter[] {new ConstructorArgument("envName", forcedEnv, true)});

                    return instance;

By setting the shouldInherit value to true you can ensure the value gets passed down the resolution chain. So it get's passed to any objects in the dependency tree that use that argument (but only for this particular instantiation).