Где происходит «волшебство», когда контроллер создает правильную реализацию интерфейса в DI Web API?

Мне кажется, что где-то кролика вытаскивают из шляпы, когда дело доходит до DI в контроллерах Web API.

Я понимаю, что: 0) Контроллер в проекте веб-API можно вызывать с различными классами, для которых создается экземпляр, каждый из которых реализует интерфейс, от которого зависит Контроллер. например, с этим кодом контроллера:

private readonly IDepartmentRepository _deptsRepository;

public DepartmentsController(IDepartmentRepository deptsRepository)
{
    if (deptsRepository == null)
    {
        throw new ArgumentNullException("deptsRepository is null");
    }
    _deptsRepository = deptsRepository;
}

... "deptsRepository" может быть классом, который реализует IDepartmentRepository и извлекает тестовые данные, ИЛИ это может быть класс, который реализует IDepartmentRepository и извлекает производственные данные, ИЛИ (и т. д.)

1) Веб-API решает, какой контроллер вызывать на основе URI, который вызывает клиент, и этот веб-API решает, какой метод в этом контроллере вызывать, основываясь на том, какой это тип (GET, POST) и т. Д., И какие аргументы, если таковые имеются, прошло с этим.

2) Castle Windsor перехватывает это автоматическое управление контроллерами с помощью собственного сменного механизма маршрутизации.

Что я не понимаю, так это то, что разработчик внедряет конкретный класс, реализующий интерфейс, ожидаемый контроллером. Итак, если я хочу запустить класс, который извлекает из тестовых данных, где я могу добавить код, чтобы указать это? Я думаю, что это будет где-то в Global.asax.cs, что-то вроде (псевдокод):

// Use test data for now
DeptsControllerClass = TestDataClass;
//DeptsControllerClass = ProductionDataClass;

IOW, где можно указать: «На этот раз я хочу, чтобы вы внедрили ЭТОТ конкретный класс, который реализует требуемый интерфейс»?

Ответы на вопрос(1)

Ваш ответ на вопрос