Pido disculpas si esto parece una repetición más de la pregunta, pero cada vez que encuentro un artículo sobre el tema, en su mayoría solo se habla de lo que es DI. Entonces, obtengo DI, pero estoy tratando de entender la necesidad de un contenedor IoC, en el que todos parecen estar metiéndose. ¿El punto de un contenedor de IoC realmente es simplemente "resolver automáticamente" la implementación concreta de las dependencias? Quizás mis clases tienden a no tener varias dependencias y tal vez por eso no veo el problema, pero quiero asegurarme de que estoy entendiendo la utilidad del contenedor correctamente.
Normalmente, rompo mi lógica de negocios en una clase que podría parecerse a esto:
public class SomeBusinessOperation
{
private readonly IDataRepository _repository;
public SomeBusinessOperation(IDataRespository repository = null)
{
_repository = repository ?? new ConcreteRepository();
}
public SomeType Run(SomeRequestType request)
{
// do work...
var results = _repository.GetThings(request);
return results;
}
}
Así que solo tiene una dependencia, y en algunos casos puede tener una segunda o tercera, pero no tan a menudo. Así que cualquier cosa que llame a esto puede pasar su propio repositorio o permitirle usar el repositorio predeterminado.
En lo que respecta a mi comprensión actual de un contenedor IoC, todo lo que hace el contenedor es resolver IDataRepository. Pero si eso es todo lo que hace, entonces no veo un montón de valor en ello ya que mis clases operativas ya definen un repliegue cuando no se transmite ninguna dependencia. Entonces, el único otro beneficio que puedo pensar es que si tengo varias operaciones como este uso del mismo repositorio alternativo, puedo cambiar ese repositorio en un lugar que es el registro / fábrica / contenedor. Y eso es genial, pero ¿es eso?