Wo geschieht die „Magie“, wenn ein Controller die korrekte Implementierung des Interfaces in Web API DI instanziiert?

Es scheint mir, dass irgendwo ein Kaninchen aus dem Hut gezogen wird, wenn es um DI in Web-API-Controllern geht.

Ich denke, dass: 0) Der Controller in einem Web-API-Projekt kann mit verschiedenen zu instanziierenden Klassen aufgerufen werden, die alle die Schnittstelle implementieren, von der der Controller abhängt. z. B. mit diesem Controller-Code:

private readonly IDepartmentRepository _deptsRepository;

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

... "deptsRepository" kann eine Klasse sein, die IDepartmentRepository implementiert und Testdaten abruft, ODER es kann eine Klasse sein, die IDepartmentRepository implementiert und Produktionsdaten abruft, ODER (usw.)

1) Die Web-API entscheidet anhand des vom Client aufgerufenen URI, welcher Controller aufgerufen wird, und die Web-API entscheidet anhand des Typs (GET, POST) usw., um welche Argumente es sich handelt damit bestanden.

2) Castle Windsor fängt diese automatische Steuerung von Controllern mit seiner eigenen Ersatzrouting-Engine ab.

Was ich nicht verstehe, ist, wo der Entwickler die konkrete Klasse einfügt, die die vom Controller erwartete Schnittstelle implementiert. IOW, wenn ich die Klasse ausführen möchte, die aus Testdaten abruft, wo füge ich Code hinzu, um das anzugeben? Ich würde denken, es wäre irgendwo in Global.asax.cs so etwas wie (Pseudocode):

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

IOW, wo gibt man an, "Dieses Mal möchte ich, dass Sie DIESE konkrete Klasse injizieren, die die erforderliche Schnittstelle implementiert"?

Antworten auf die Frage(1)

Ihre Antwort auf die Frage