Где происходит «волшебство», когда контроллер создает правильную реализацию интерфейса в 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 перехватывает это автоматическое управление контроллерами с помощью собственного сменного механизма маршрутизации.
Что я не делаюИменно в grok разработчик внедряет конкретный класс, реализующий интерфейс, ожидаемый контроллером. Итак, если я хочу запустить класс, который извлекает из тестовых данных, где я могу добавить код, чтобы указать это? Я думаю, что это будет где-то в Global.asax.cs, что-то вроде (псевдокод):
// Use test data for now
DeptsControllerClass = TestDataClass;
//DeptsControllerClass = ProductionDataClass;
IOW, где можно указать "На этот раз я хочу, чтобы вы внедрили ЭТОТ конкретный класс, который реализует требуемый интерфейс "?