Получите экземпляр контейнера для Simple Injector

За исключением любого кода, который является частью пути запуска приложения, никакой код не должен напрямую зависеть от контейнера (или абстракции контейнера, фасада контейнера и т. Д.). Этот шаблон называется Service Locator и Марк Земанн имеет хорошее объяснение почему это плохая идея.

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

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

Для этой проблемы существует общий шаблон: шаблон проектирования абстрактной фабрики. Шаблон фабрики позволяет отложить создание типов и позволяет передавать дополнительные параметры времени выполнения для создания определенного типа. Когда вы это делаете, ваш контроллер не должен зависеть от контейнера и избавляет вас от необходимости передавать сконструированный контейнер в ваших модульных тестах (структуры DI, как правило, не должны использоваться в ваших проектах модульного тестирования).

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

Вы можете подумать, что, делая это, мы просто переносим проблему на фабричную реализацию. Хотя мы переносим зависимость от контейнера в реализацию фабрики, мы фактически решаем проблему, поскольку реализация фабрики будет частью Composition Root, который позволяет самому коду приложения игнорировать любую структуру DI.

Вот как я советую вам структурировать свой код:

// Definition of the factory in the UI or BL layer
public interface ISomeServiceFactory
{
    ISomeService Create(int inputParameter);
}

// Controller depending on that factory:
public class MyController : Controller
{
    private readonly ISomeServiceFactory factory;

    public MyController(ISomeServiceFactory factory)
    {
        this.factory = factory;
    }

    public ActionResult Index(int value)
    {
        // here we use that factory
        var service = this.factory.Create(value);
    }
}

В корне вашей композиции (путь запуска) мы определяем реализацию фабрики и регистрацию для нее:

private class SomeServiceFactory : ISomeServiceFactory
{
    private readonly Container container;

    // Here we depend on Container, which is fine, since
    // we're inside the composition root. The rest of the
    // application knows nothing about a DI framework.
    public SomeServiceFactory(Container container)
    {
        this.container = container;
    }

    public ISomeService Create(int inputParameter)
    {
        // Do what ever we need to do here. For instance:
        if (inputParameter == 0)
            return this.container.GetInstance<Service1>();
        else
            return this.container.GetInstance<Service2>();
    }
}

public static void Initialize()
{
    var container = new Container();

    container.RegisterSingle<ISomeServiceFactory, SomeServiceFactory>();
}

После создания Container регистрируется (с помощью вызова RegisterSingle<Container>(this)), поэтому вы всегда можете вставить контейнер в любой компонент. Это похоже на введение IComponentContext при работе с Autofac. Но то же самое относится к Autofac, Simple Injector и любому другому контейнеру: вы не хотите внедрять свой контейнер в компоненты, расположенные за пределами корня композиции (и для этого вряд ли когда-либо есть причина).