Si no es necesario ningún procedimiento especial, un contenedor DI puede ser muy corta:
public class Container
{
private readonly Dictionary<Type,Func<Container,object>> factories;
private readonly Dictionary<Type,object> cache;
public Container()
{
this.factories = new Dictionary<Type,Func<Container,object>>();
this.cache = new Dictionary<Type,object>();
}
public void Register<TContract>(Func<Container,TContract> factory)
{
// wrap in lambda which returns object instead of TContract
factories[typeof(TContract)] = c => factory(c);
}
public TContract Get<TContract>()
{
var contract = typeof(TContract);
if (!cache.ContainsKey(contract))
{
this.cache[contract] = this.factories[contract](this);
}
return (TContract)this.cache[contract];
}
}
cual se utilizaría la siguiente manera:
var container = new Container();
container.Register<ICar>(c => new Car(
c.Get<IEngine>(), c.Get<IWheel>()));
container.Register<IWheel>(c => new Wheel());
container.Register<IEngine>(c => new Engine());
var car = container.Get<ICar>();
Aún más minimalista habría que hacer la dependencia inyección sin un contenedor:
IWheel wheel = new Wheel();
IEngine engine = new Engine();
ICar car = new Car(engine, wheel);
sin embargo, para los gráficos de objetos complejos se pueden obtener rápidamente compli para mantener el orden de construcción correcto durante las refactorizaciones. El contenedor no tiene este problema.
Es posible que desee etiquetar este .net para obtener más sugerencias. –
mire esta pregunta: http://stackoverflow.com/questions/2515124/whats-the-simplest-ioc-container-for-c hay un ejemplo en línea –
Si está escribiendo una biblioteca, no debería tener que use un Contenedor DI en absoluto: http://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library/2047657#2047657 –