Внедрение зависимостей и шаблон стратегии

Насколько я могу судить, этот вопрос касается выбора во время выполнения или отображения одной из нескольких возможных Стратегий.

Нет причин полагаться на контейнер DI для этого, поскольку есть как минимум три способа сделать это независимо от контейнера:

• Используйте подсказку о ролях метаданных
• Используйте подсказку о роли интерфейса
• Используйте подсказку о роли частичного имени типа

Мое личное предпочтение - Подсказка роли частичного имени типа.

Я достиг этого требования во многих формах за последние пару лет. Во-первых, давайте выделим основные моменты, которые я вижу в вашем сообщении

предположить выбор стратегий во время выполнения и использование контейнера IOC ... добавить предположение, что необходимо выбирать не одну стратегию. Скорее, мне может потребоваться получить объект-граф, который имеет несколько стратегий ... [не должен] связывать вызывающий объект с контейнером IOC ... Каждую новую стратегию необходимо [не обязательно] вручную добавлять в список привязок. .. Было бы неплохо, если бы контейнер IOC просто помогал немного больше.

Я использовал Simple Injector в качестве контейнера в течение некоторого времени, и одним из драйверов для этого решения является то, что он имеет обширный поддержка дженериков. Именно с помощью этой функции мы реализуем ваши требования.

Я твердо уверен, что код должен говорить сам за себя, поэтому сразу приступлю ...

• Я определил дополнительный класс ContainerResolvedClass<T>, чтобы продемонстрировать, что Simple Injector находит правильные реализации и успешно внедряет их в конструктор. Это единственная причина для класса ContainerResolvedClass<T>. (Этот класс предоставляет обработчики, которые вводятся в него для тестовых целей через result.Handlers.)

Этот первый тест требует, чтобы мы вернули одну реализацию для вымышленного класса Type1:

[Test]
public void CompositeHandlerForType1_Resolves_WithAlphaHandler()
{
    var container = this.ContainerFactory();

    var result = container.GetInstance<ContainerResolvedClass<Type1>>();
    var handlers = result.Handlers.Select(x => x.GetType());

    Assert.That(handlers.Count(), Is.EqualTo(1));
    Assert.That(handlers.Contains(typeof(AlphaHandler<Type1>)), Is.True);
}

Этот второй тест требует, чтобы мы вернули одну реализацию для вымышленного класса Type2:

[Test]
public void CompositeHandlerForType2_Resolves_WithAlphaHandler()
{
    var container = this.ContainerFactory();

    var result = container.GetInstance<ContainerResolvedClass<Type2>>();
    var handlers = result.Handlers.Select(x => x.GetType());

    Assert.That(handlers.Count(), Is.EqualTo(1));
    Assert.That(handlers.Contains(typeof(BetaHandler<Type2>)), Is.True);
}

Этот третий тест требует, чтобы мы вернули две реализации для вымышленного класса Type3:

[Test]
public void CompositeHandlerForType3_Resolves_WithAlphaAndBetaHandlers()
{
    var container = this.ContainerFactory();

    var result = container.GetInstance<ContainerResolvedClass<Type3>>();
    var handlers = result.Handlers.Select(x => x.GetType());

    Assert.That(handlers.Count(), Is.EqualTo(2));
    Assert.That(handlers.Contains(typeof(AlphaHandler<Type3>)), Is.True);
    Assert.That(handlers.Contains(typeof(BetaHandler<Type3>)), Is.True);
}

Кажется, что эти тесты соответствуют вашим требованиям, и, что лучше всего, в решении не повреждены контейнеры.

Уловка состоит в том, чтобы использовать комбинацию объектов параметров и интерфейсов маркеров. Объекты параметров содержат данные для поведения (т.е. IHandler), а интерфейсы маркеров определяют, какое поведение воздействует на какие объекты параметров.

Вот интерфейсы маркеров и объекты параметров - вы заметите, что Type3 отмечен обоими интерфейсами маркеров:

private interface IAlpha { }
private interface IBeta { }

private class Type1 : IAlpha { }
private class Type2 : IBeta { }
private class Type3 : IAlpha, IBeta { }

Вот поведение (IHandler<T>):

private interface IHandler<T> { }

private class AlphaHandler<TAlpha> : IHandler<TAlpha> where TAlpha : IAlpha { }
private class BetaHandler<TBeta> : IHandler<TBeta> where TBeta : IBeta { }

Это единственный метод, который найдет все реализации открытого дженерика:

public IEnumerable<Type> GetLoadedOpenGenericImplementations(Type type)
{
    var types =
        from assembly in AppDomain.CurrentDomain.GetAssemblies()
        from t in assembly.GetTypes()
        where !t.IsAbstract
        from i in t.GetInterfaces()
        where i.IsGenericType
        where i.GetGenericTypeDefinition() == type
        select t;

    return types;
}

И это код, который настраивает контейнер для наших тестов:

private Container ContainerFactory()
{
    var container = new Container();

    var types = this.GetLoadedOpenGenericImplementations(typeof(IHandler<>));

    container.RegisterAllOpenGeneric(typeof(IHandler<>), types);

    container.RegisterOpenGeneric(
        typeof(ContainerResolvedClass<>),
        typeof(ContainerResolvedClass<>));

    return container;
}

И, наконец, тестовый класс ContainerResolvedClass<>

private class ContainerResolvedClass<T>
{
    public readonly IEnumerable<IHandler<T>> Handlers;

    public ContainerResolvedClass(IEnumerable<IHandler<T>> handlers)
    {
        this.Handlers = handlers;
    }
}

Я понимаю, что этот пост довольно длинный, но я надеюсь, что он ясно демонстрирует возможное решение вашей проблемы ...

Это запоздалый ответ, но, возможно, он поможет другим.

У меня довольно простой подход. Я просто создаю StrategyResolver, чтобы не зависеть напрямую от Unity.

public class StrategyResolver : IStrategyResolver
{
    private IUnityContainer container;

    public StrategyResolver(IUnityContainer unityContainer)
    {
        this.container = unityContainer;
    }

    public T Resolve<T>(string namedStrategy)
    {
        return this.container.Resolve<T>(namedStrategy);
    }
}

Использование:

public class SomeClass: ISomeInterface
{
    private IStrategyResolver strategyResolver;

    public SomeClass(IStrategyResolver stratResolver)
    {
        this.strategyResolver = stratResolver;
    }

    public void Process(SomeDto dto)
    {
        IActionHandler actionHanlder = this.strategyResolver.Resolve<IActionHandler>(dto.SomeProperty);
        actionHanlder.Handle(dto);
    }
}

Регистрация:

container.RegisterType<IActionHandler, ActionOne>("One");
container.RegisterType<IActionHandler, ActionTwo>("Two");
container.RegisterType<IStrategyResolver, StrategyResolver>();
container.RegisterType<ISomeInterface, SomeClass>();

Самое приятное в этом то, что мне никогда больше не придется прикасаться к StrategyResolver, когда я добавляю новые стратегии в будущем.

Все очень просто. Очень чисто, и я свел зависимость от Unity до минимума. Единственный раз, когда я прикоснусь к StrategyResolver, - это если я решу изменить технологию контейнера, что вряд ли произойдет.

Надеюсь это поможет!

Обычно я использую комбинацию параметров Абстрактная фабрика и Именованные привязки. Попробовав много разных подходов, я нахожу этот подход достойным балансом.

Что я делаю, так это создаю фабрику, которая по существу обертывает экземпляр контейнера. См. Раздел статьи Марка под названием Фабрика на основе контейнеров . Как он предлагает, я делаю эту фабрику частью корня композиции.