Home/ Questions/Q 9203293
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T23:26:29+00:00

Is it possible to configure multiple implementations of the same interface with the autofac

  • 0

Is it possible to configure multiple implementations of the same interface with the autofac xml configuration?

What i’m trying to accomplish is a windows service which executes multiple jobs. I have 2 jobs which are sending messages from a queue by sms or email. Every job is a different assembly. They both depend on IQueuedMessageProvider. One job needs the email implementation the other one the sms implementation.The constructor for both jobs look like this (simplified for question):

 public SendSmsJob(IQueuedMessageProvider queuedMessageProvider)
    {
        _queuedMessageProvider= queuedMessageProvider;
    }
 public SendEmailJob(IQueuedMessageProvider queuedMessageProvider)
    {
        _queuedMessageProvider= queuedMessageProvider;
    }

In the app.config I registered the implementations like

<component type="MyApp.Plugin.Sms.Verizon.VerizonSmsService, MyApp.Plugin.Sms.Verizon" service="MyApp.Model.Messages.QueuedMessages.Providers.IQueuedMessageProvider, MyApp.Model" />
<component type="MyApp.Plugin.Email.Smtp.EmailService, MyApp.Plugin.Email" service="MyApp.Model.Messages.QueuedMessages.Providers.IQueuedMessageProvider, MyApp.Model" />

How can I make sure the job gets the right implementation of de IQueuedMessageProvider? I have read about solving these kind of problems with names and keys https://code.google.com/p/autofac/wiki/TypedNamedAndKeyedServices.

Another option is register all implementations and make IQueuedMessageProvider an IEnumerable and take the right implementation in the constructor. But I prefer to solve it in the configuration it self. Is it even possible or do you have any better suggestions about solving this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Autofac’s XML configuration, at the time of this writing, has the ability to specify a name/key for a service (like your message providers) but can’t specify that a given type on a different service’s constructor (the “job” classes) get associated with a particular name.

    You have effectively three options.

    Option 1: Redesign your interfaces

    The point of having an interface (or an abstract/base class) is that you can use implementations interchangeably. (See: Liskov substitution principle.) If your design is such that you can’t do that (which is how it appears) then it would be good to reinvestigate that design. You might need different interfaces for different tasks.

    Looking at the small snippet provided, I might think about having different interfaces for each method of transport (ISmsProvider, IEmailProvider) so the processor “job” classes can key appropriately by type.

    Option 2: Use Autofac modules

    If you have different “known configurations” (e.g., one for development, one for production) then you could create different Autofac modules for each configuration. You can be much more flexible in a module than you can in XML configuration and it would allow you to do the fancy wire-up-by-named-instance stuff you need to do.

    You can use XML configuration to register modules just like you can for types, so rather than switching the XML config type registrations based on your different requirements, change the XML config to register a different module.

    Option 3: Implement your own XML config parser

    As of Autofac 3.0, the configuration mechanism has a way to write your own mechanism that parses and registers XML configuration. The documentation on the site isn’t updated quite yet, and there’s no “cookbook” or sample, so you’ll have to do some spelunking in the source, but technically it’s possible. I’d probably look at one of the first two options before diving into this one.

    • 0