Onde está acontecendo a "mágica" quando um Controller instancia a implementação correta da Interface na Web API DI?
Parece-me que em algum lugar um coelho está sendo puxado de um chapéu quando se trata de DI em Web API Controllers.
Eu entendo que: 0) O Controller em um projeto de API da Web pode ser chamado com várias classes a serem instanciadas, todas implementando a interface da qual o Controller depende. por exemplo, com este código do controlador:
private readonly IDepartmentRepository _deptsRepository;
public DepartmentsController(IDepartmentRepository deptsRepository)
{
if (deptsRepository == null)
{
throw new ArgumentNullException("deptsRepository is null");
}
_deptsRepository = deptsRepository;
}
... "deptsRepository" pode ser uma classe que implementa IDepartmentRepository e recupera dados de teste, OU pode ser uma classe que implementa IDepartmentRepository e recupera dados de produção, OU (etc.)
1) A API da Web decide qual Controlador é chamado com base no URI que o cliente chama e que a API da Web decide qual método nesse Controlador é chamado com base em qual tipo (GET, POST) etc. é e quais argumentos, se houver, são passou com ele.
2) O Castle Windsor intercepta esse controle automático dos controladores com seu próprio mecanismo de roteamento de substituição.
O que eu não entendo é exatamente onde o desenvolvedor injeta a classe concreta que implementa a interface esperada pelo Controller. IOW, se eu quiser executar a classe que extrai dos dados de teste, onde adiciono código para especificar isso? Eu acho que estaria em algum lugar no Global.asax.cs, algo como (pseudocódigo):
// Use test data for now
DeptsControllerClass = TestDataClass;
//DeptsControllerClass = ProductionDataClass;
IOW, onde se especifica: "Desta vez, quero que você injete ESTA classe concreta que implementa a interface necessária"?