Wydaje mi się, że gdzieś królik jest wyciągany z kapelusza, jeśli chodzi o DI w kontrolerach Web API.

Grokuję, że: 0) Kontroler w projekcie Web API może być wywoływany z różnymi klasami do utworzenia instancji, z których wszystkie implementują interfejs, od którego zależy Kontroler. np. za pomocą tego kodu kontrolera:

private readonly IDepartmentRepository _deptsRepository;

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

... "deptsRepository" może być klasą, która implementuje IDepartmentRepository i pobiera dane testowe, LUB może to być klasa, która implementuje IDepartmentRepository i pobiera dane produkcyjne, OR (itd.)

1) Web API decyduje, który kontroler jest wywoływany na podstawie identyfikatora URI wywołanego przez klienta, a ten interfejs WWW decyduje, która metoda w tym kontrolerze jest wywoływana na podstawie typu (GET, POST) itd. I jakie argumenty, jeśli są, przeszedł z nim.

2) Castle Windsor przechwytuje tę automatyczną kontrolę kontrolerów z własnym silnikiem zastępczym.

To, czego nie grokuję, to miejsce, w którym deweloper wprowadza konkretną klasę, która implementuje interfejs oczekiwany przez kontroler. IOW, jeśli chcę uruchomić klasę, która pobiera z danych testowych, gdzie mogę dodać kod, aby to określić? Myślę, że będzie to gdzieś w Global.asax.cs, coś w rodzaju (pseudokod):

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

IOW, gdzie można określić „Tym razem chcę, abyś wstrzyknął klasę THIS, która implementuje wymagany interfejs”?