Resolve Service Implementation from Autofac based on Runtime Session Value

Question

Need some help trying to solve a problem resolving an implementation of a service at runtime based on a parameter. In other words use a factory pattern with DI.

We have Autofac wired in to our MVC application. I am trying to figure out how we can use a user session variable (Call it Ordering Type) to be used for the Dependency Resolver to resolve the correct implementation of a service.

An example of what we are trying to do.

The application has two "types" of ordering - real eCommerce type of ordering (add stuff to a shopping cart, checkout etc).

The other is called Forecast ordering. Users create orders - but they do not get fulfilled right away. They go through an approval process and then fulfilled.

The bottom line is the data schema and back end systems the application talks to changes based on the order type.

What I want to do is:

1. I have IOrderManagerService

   public interface IOrderManagerService
   {
         Order GetOrder(int orderNumber);
         int CreateOrder(Order order);
   }
   

2. Because we have two ordering "types" - I have two implementations of the the IOrderManagerService:

   public class ShelfOrderManager : IOrderManagerService
   {
       public Order GetOrder(int orderMumber)
       {
            ...code
       }
   
       public int CreateOrder(Order order)
       {
           ...code
       }
   }
   

and

    public class ForecastOrderManager: IOrderManagerService
    {
        public Order GetOrder(int orderMumber)
        {
             ...code
        }

        public int CreateOrder(Order order)
        {
            ...code
        }
    }

3. My First question is - in my MVC application - do I register these implementations as?

   builder.RegisterType<ShelfOrderManager>().As<IOrderManagerService>();
   builder.RegisterType<ForecastOrderManager>().As<IOrderManagerService>();
   

4. What we are planning on doing is sticking the user selected ordering type in a users session. When a user wants to view order status - depending on their selected ordering "type" - I need the resolver to give the controller the correct implementation.

   public class OrderStatusController : Controller
   {
         private readonly IOrderManagerService _orderManagerService;
   
         public OrderStatusController(IOrderManagerService orderManagerService)
         {
              //This needs to be the correct implementation based on the users "type".  
              _orderManagerService = orderManagerService; 
         }
   
         public ActionResult GetOrder(int orderNumber)
         {
              var model = _orderManagerService.GetOrder(orderNumber);
              return View(model);
         }
   }
   

I've ready about the the delegate factory and this answer explains the concept well.

The problem is the runtime parameters are being used to construct the service and resolve at runtime. i.e.

     var service = resolvedServiceClass.Factory("runtime parameter")

All this would do is give me "service" that used the "runtime parameter" in the constructor.

I've looked at Keyed or Named resolution too.

At first I thought I could combine these two techniques - but the controller has the dependency on the interface - not the concrete implementation. (as it should)

Any ideas on how to get around this would be MUCH appreciated.

Answer 1

As it would turn out we were close. @Andrei is on target with what we did. I'll explain the answer below for the next person that comes across this issue.

To recap the problem - I needed to resolve a specific concrete implementation of an interface using Autofac at run time. This is commonly solved by the Factory Pattern - but we already had DI implemented.

The solution was using both. Using the delegate factory Autofac supports, I created a simple factory class.

I elected to resolve the component context privately

   DependencyResolver.Current.GetService<IComponentContext>();

versus having Autofac resolve it predominately so I did not have to include IComponentContext in all of my constructors that that will be using the factory.

The factory will be used to resolve the services that are dependent on run time parameters - which means wherever a

  ISomeServiceThatHasMultipleImplementations 

is used in a constructor - I am going to replace it with ServiceFactory.Factory factory. I did not want to ALSO include IComponentContext wherever I needed the factory.

enum OrderType 
{
    Shelf,
    Forecast
 }

public class ServiceFactory : IServiceFactory
{
    private readonly IComponentContext _componentContext;
    private readonly OrderType _orderType;
    public ServiceFactory(OrderType orderingType)
    {
        _componentContext = DependencyResolver.Current.GetService<IComponentContext>();
        _orderType = orderingType;
    }

    public delegate ServiceFactory Factory(OrderType orderingType);

    public T Resolve<T>()
    {
        if(!_componentContext.IsRegistered<T>())
            return _componentContext.ResolveNamed<T>(_orderType.ToString());

        return _componentContext.Resolve<T>();
    }
}

With the factory written, we also used the Keyed services.

Using my order context -

public interface IOrderManagerService
{
    Order GetOrder(int orderNumber);

    int CreateOrder(Order order);
}

public class ShelfOrderManager : IOrderManagerService
{
    public Order GetOrder(int orderNumber)
    {
        ...
    }

    public int CreateOrder(Order order)
    {
        ...
    }
}

public class ForecastOrderManager : IOrderManagerService
{
    public Order GetOrder(int orderNumber)
    {
        ...
    }

    public int CreateOrder(Order order)
    {
       ...
    }
}

The registration of Keyed services:

        //register the shelf implementation
        builder.RegisterType<ShelfOrderManager>()
            .Keyed(OrderType.Shelf)
            .As<IOrderManager>();

        //register the forecast implementation
        builder.RegisterType<ForecastOrderManager>()
            .Keyed(OrderType.Shelf)
            .As<IOrderManager>();

Register the factory:

 builder.RegisterType<IMS.POS.Services.Factory.ServiceFactory>()
            .AsSelf()
            .SingleInstance();

Finally using it in the controllers (or any other class for that matter):

public class HomeController : BaseController
{
    private readonly IContentManagerService _contentManagerService;
    private readonly IViewModelService _viewModelService;
    private readonly IApplicationSettingService _applicationSettingService;
    private readonly IOrderManagerService _orderManagerService;
    private readonly IServiceFactory _factory;

    public HomeController(ServiceFactory.Factory factory,
                                    IViewModelService viewModelService, 
                                    IContentManagerService contentManagerService, 
                                    IApplicationSettingService applicationSettingService)
    {
        //first assign the factory
        //We keep the users Ordering Type in session - if the value is not set - default to Shelf ordering
        _factory = factory(UIUserSession?.OrderingMode ?? OrderType.Shelf);

        //now that I have a factory to get the implementation I need
        _orderManagerService = _factory.Resolve<IOrderManagerService>();

        //The rest of these are resolved by Autofac
        _contentManagerService = contentManagerService;
        _viewModelService = viewModelService;
        _applicationSettingService = applicationSettingService;

    }
}

I want to work out a bit more handling of the Resolve method - but for the first pass this works. A little bit Factory Pattern (where we need it) but still using Autofac to do most of the work.

Answer 2

I would not rely on Autofac for this. IOC is used to resolve a dependency and provide an implementation for it, what you need is to call a different implementation of the same interface based on a decision flag.

I would use a simple factory basically, like a class with 2 static methods and call whichever implementation you need need to when you know what the decision is. This gives you the run-time resolver you are after. Keep it simple I'd say.

This being said it seems there is another option. Have a look at the "select by context" option, maybe you can redesign your classes to take advantage of this: http://docs.autofac.org/en/latest/faq/select-by-context.html