Inject different implementations of an Interface to a command at runtime

Question

I have an interface in my project that 2 classes implement it:

public interface IService
{
   int DoWork();
}

public class Service1:IService
{
    public int DoWork()
    {
       return 1;
    }
}  

public class Service2:IService
{
    public int DoWork()
    {
       return 2;
    }
}    

I have a command handler that depends on IService too:

public CommandHandler1:ICommandHandler<CommandParameter1>
{
     IService _service;  
     public CommandHandler1(IService service)
     {
          _service = service
     }  
     public void Handle()
     { 
          //do something
          _service.DoWork();
          //do something else 
     }
}

public interface ICommandHandler<TCommandParameter> 
                 where TCommandParameter :ICommandParameter
{
    void Handle(TCommandParameter parameter);
}
public interface ICommandParameter
{
}

I want to inject Service1 or Service2 to my CommandHandler1 based on user selection. suppose that I have an enum and user could select a value from it:

public enum Services
{  
    Service_One,
    Service_Two 
}

If user selects Service_One I want inject Service1 to my command handler and If he selects Service_Two I want inject Service2 to the command handler.

I know that I can use named instances, and then call ObjectFactory.GetInstance<IService>().Named("Service1") for example, but Is there any way to implement this by StructureMap and prevent using Service Locator pattern?

Answer 1

Prevent building your object graphs using runtime conditions. Object graphs should be fixed. Use runtime decisions to determine the path through the object graph.

What you seem to be missing here is an abstraction that allows delegating the request to the correct IService implementation; let's call it IServiceDispatcher:

interface IServiceDispatcher
{
    int DoWork(Services data);
}

sealed class ServiceDispatcher : IServiceDispatcher
{
    private readonly IService service1;
    private readonly IService service2;

    // NOTE: Feel free to inject the container here instead, as long as
    // this class is part of your composition root.
    public ServiceDispatcher(IService service1, IService service2)
    {
        this.service1 = service1;
        this.service2 = service2;
    }

    public int DoWork(Services data)
    {
        return this.GetService(data).DoWork();
    }

    private IService GetService(Services data)
    {
        switch (data)
        {
            case Services.Service_One: return this.service1;
            case Services.Service_Two: return this.service2;
            default: throw new InvalidEnumArgumentException();
        }
    }
}

Now your CommandHandler1 can depend on IServiceDispatcher:

public CommandHandler1 : ICommandHandler<CommandParameter1>
{
    private readonly IServiceDispatcher serviceDispatcher;
    public CommandHandler1(IServiceDispatcher serviceDispatcher)
    {
         this.serviceDispatcher = serviceDispatcher;
    }  

    public void Handle(CommandParameter1 commandParameter)
    { 
         //do something
         this.serviceDispatcher.DoWork(commandParameter.Service);
         //do something else 
    }
}

Do note that IServiceDispatcher is a really ugly name that technically describes what's going on. This is a bad idea, because the interface should functionally describe what you want. But since you didn't supply any domain-specific context to your question, this is the best name I can come up with ;-)

Answer 2

This may not be the best approach but it should work.

Add a property to each service that specifies the ServiceTypes it represents:

public interface IService
{
    public ServiceTypes Type { get; }

    public int DoWork();
}

Implement the property in each class:

public class Service1 : IService
{
    public ServiceTypes Type { get { return ServiceTypes.Service_One; } }

    public void DoWork()
    {
        return 1;
    }
}

Then, register all the implementations of your service in the container and inject them in your handler. From there, select the implementation based on a property from the command:

container.For<IService>().Use<Service1>("service1");
container.For<IService>().Use<Service2>("service2");

Add the required ServiceType in the command class:

public class Command1
{
    // Other command properties

    public ServiceTypes Service { get; set; }
}

And in the command handler:

public class CommandHandler : ICommandHandler<Command1>
{
    private readonly IEnumerable<IService> _services;

    public CommandHandler(IService[] services)
    {
        _servies = services;
    }

    public void Handle(Command1 command)
    {
        var service = _services.Single(s => s.Type == command.Service);
        service.DoWork();
    }
}

Answer 3

I would create a factory, that has reference to IContext and uses it to resolve the concrete service dependency.

public interface ICommandFactory
{
    Command1 CreateCommand(Services serviceType);
}

public class CommandFactory : ICommandFactory
{
    private readonly IContext _context;

    public CommandFactory(IContext context)
    {
        _context = context;
    }

    public Command1 CreateCommand(Services serviceType)
    {
        IService service;
        switch(serviceType)
        {
            case Services.Service_One: service = _context.GetInstance<Service1>();
                break;
            case Services.Service_Two: service = _context.GetInstance<Service2>();
                break;
            default:
                throw new ArgumentOutOfRangeException("serviceType", serviceType, null);
        }

        return new Command1(service);
    }
}

And then, you register and use it like this:

var container = new Container(_ =>
{
    _.For<ICommandFactory>().Use(context=>new CommandFactory(context));
});

var factory = container.GetInstance<ICommandFactory>();

var command = factory.CreateCommand(Services.Service_One);
command.Handle();

First, the responsibility of picking the right service is separate from the command itself. It also allows command to have different dependencies on top of the service itself, just call _context.GetInstance<TypeOfDependency>().

About this being same as Service Locator. The major problem of service locator is that it hides dependencies. This is not case here, because the one calling the command explicitly states dependency on the CommandFactory class. And if interface is introduced for the factory class (turning it into AbstractFactory pattern), then the implementation itself can become part of the dependency resolution strategy. Eg. it will be in same place as the dependency framework itself. Thanks to this there is no Service Locator (static or interface) within the domain model.