Как я могу разрешить декораторы для объектов, созданных фабрикой, в Simple Injector

Simple Injector не позволяет регистрировать несколько конкретных реализаций одного и того же интерфейса.

Это утверждение неверно. На самом деле есть несколько способов сделать это. Я думаю, что три наиболее распространенных способа сделать это:

1. Использовать условную регистрацию
2. Зарегистрируйте коллекцию типов
3. Вручную создайте InstanceProducer экземпляров.

Варианты 1 и 3 кажутся наиболее подходящими в вашем случае, поэтому давайте начнем с варианта 3: Создание InstanceProducers:

// Create two providers for IProvider according to the required lifestyle.
var bing = Lifestyle.Singleton.CreateProducer<IProvider, BingProvider>(container);
var google = Lifestyle.Singleton.CreateProducer<IProvider, GoogleProvider>(container);

container.RegisterSingleton<ProviderFactory>(new ProviderFactory(provider => {
    switch (provider) {
        case "Bing": return bing.GetInstance();
        case "Google": return google.GetInstance();
        default: throw new ArgumentOutOfRangeException();
    }
}));

Здесь мы создаем два InstanceProducer экземпляра, по одному для каждого IProvider. Важной частью здесь является создание производителя для абстракции IProvider, поскольку это позволяет применять декораторы для IProvider.

В качестве альтернативы вы можете переместить оператор _8 _-_ 9_ внутрь ProviderFactory и снабдить его двумя отдельными делегатами; по одному на каждого провайдера. Например:

public ProviderFactory(Func<IProvider> bingProvider, Func<IProvider> googleProvider) { .. }

public IProvider Get(string provider) {
    switch (provider) {
        case "Bing": return bingProvider();
        case "Google": return googleProvider();
        default: throw new ArgumentOutOfRangeException();
    }
}

Регистрация очень похожа на предыдущую:

var bing = Lifestyle.Singleton.CreateProducer<IProvider, BingProvider>(container);
var google = Lifestyle.Singleton.CreateProducer<IProvider, GoogleProvider>(container);

container.RegisterSingleton<ProviderFactory>(new ProviderFactory(
    bingProvider: bing.GetInstance,
    googleProvider: google.GetInstance));

Вместо того, чтобы вводить Func<T> делегатов в фабрику, в зависимости от ваших потребностей, вы можете напрямую внедрить IProvider. Это означает, что ваш конструктор будет выглядеть следующим образом:

public ProviderFactory(IProvider bing, IProvider google) { ... }

Теперь вы можете использовать условную регистрацию для IProvider, чтобы устранить двусмысленность аргументов конструктора:

container.RegisterSingleton<ProviderFactory>();
container.RegisterConditional<IProvider, BingProvider>(
    c => c.Consumer.Target.Name == "bing");
container.RegisterConditional<IProvider, GoogleProvider>(
    c => c.Consumer.Target.Name == "google");

Преимущество этого в том, что вы не откладываете создание графа объекта; все поставщики вводятся напрямую после разрешения потребителя фабрики.

В качестве альтернативы вы также можете поэкспериментировать с дизайном, в котором вы заменяете фабрику абстракцией диспетчера. Фабричные абстракции часто не являются самым простым решением для потребителя, потому что теперь им приходится иметь дело как с типом фабрики, так и с возвращаемой абстракцией службы. С другой стороны, диспетчер или процессор предоставляет потребителю одну-единственную абстракцию. Это часто упрощает потребителя (и его модульные тесты).

Такой диспетчер будет очень похож на сам интерфейс IProvider, но добавляет параметр string provider к своим методам экземпляра. Например:

interface IProviderDispatcher {
    void DoSomething(string provider, ProviderData data);
}

Где реализация диспетчера может выглядеть так:

public ProviderDispatcher(IProvider bing, IProvider google) { .. }

public void DoSomething(string provider, ProviderData data) {
    this.Get(provider).DoSomething(data);
}

private IProvider Get(string provider) {
    switch (provider) {
        case "Bing": return this.bing;
        case "Google": return this.google;
        default: throw new ArgumentOutOfRangeException();
    }
}

Решение для диспетчера может быть таким же af для фабрики, но теперь мы скрываем лишний шаг от потребителя.

Было бы даже лучше, если бы мы могли полностью удалить IProviderDispatcher абстракцию, но это возможно только в том случае, если string provider данные времени выполнения являются контекстными данными, доступными во время запроса. В этом случае мы могли бы сделать следующее:

interface IProviderContext {
    string CurrentProvider { get; }
}

И вместо отдельной абстракции провайдера у нас может быть реализация прокси на IProvider:

class ProviderDispatcherProxy : IProvider {
    public ProviderDispatcherProxy(Func<IProvider> bingProvider, 
        Func<IProvider> googleProvider,
        IProviderContext providerContext) { ... }

    void IProvider.DoSomething(ProviderData data) {
        // Dispatch to the correct provider
        this.GetCurrentProvider.DoSomething(data);
    }

    private IProvider GetCurrentProvider() =>
        switch (this.providerContext.CurrentProvider) {
            case "Bing": return this.bingProvider();
            case "Google": return this.googleProvider();
            default: throw new ArgumentOutOfRangeException();
        }
    };
}

class AspNetProviderContext : IProviderContext {
    public CurrentProvider => HttpContext.Current.Request.QueryString["provider"];
}

Опять же, внутренне он по-прежнему очень похож на предыдущий, но теперь, поскольку значение поставщика - это то, что мы можем решить из доступного внешнего контекста (HttpContext.Current), мы сможем позволить потребителю работать с IProvider напрямую. Вы можете зарегистрировать это следующим образом:

container.RegisterSingleton<IProviderContext>(new AspNetProviderContext());

var bing = Lifestyle.Singleton.CreateProducer<IProvider, BingProvider>(container);
var google = Lifestyle.Singleton.CreateProducer<IProvider, GoogleProvider>(container);
container.RegisterSingleton<IProvider>(new ProviderDispatcherProxy(
    bingProvider: bing.GetInstance,
    googleProvider: google.GetInstance));

Теперь вы можете просто ввести IProvider своим потребителям, и отправка будет происходить автоматически в фоновом режиме.