.net - type - unity ioc

¿Cómo sabe Unity.Resolve qué constructor usar?

Question

Dada una clase con varios constructores, ¿cómo puedo decirle a Resolver qué constructor usar?

Considere la siguiente clase de ejemplo:

public class Foo
{
public Foo() { }
public Foo(IBar bar)
{
Bar = bar;
}
public Foo(string name, IBar bar)
{
Bar = bar;
Name = name;
}
public IBar Bar { get; set; }
public string Name { get; set; }
}

Si quiero crear un objeto de tipo Foo usando Resolver, ¿cómo sabrá Resolver qué constructor usar? ¿Y cómo puedo decirle que use el correcto? Digamos que tengo un contenedor con un IBar registrado. ¿Comprenderá que debería favorecer al constructor que toma IBar? Y si también especifico una cadena, ¿usará el constructor (string, IBar) ?

Foo foo = unityContainer.Resolve<Foo>();

E ignore el hecho de que probablemente sería más fácil si la clase tuviera un solo constructor ...

Answer 1

Cuando una clase de destino contiene más de un constructor, Unity usará el que tiene aplicado el atributo InjectionConstructor. Si hay más de un constructor y ninguno lleva el atributo InjectionConstructor, Unity usará el constructor con la mayoría de los parámetros. Si hay más de uno de estos constructores (más de uno de los "más largos" con el mismo número de parámetros), Unity generará una excepción.

Tomado del texto del enlace

Answer 2

Cuando registra el tipo, puede especificar qué constructor usar como este:

container.RegisterType<Foo>(
new InjectionConstructor(
new ResolvedParameter<IBar>()));

El código anterior proviene de la memoria, pero ese es el principio general. En este caso, elegí el constructor que toma un único parámetro de tipo IBar.

E ignore el hecho de que probablemente sería más fácil si la clase tuviera un solo constructor ...

No puedo ignorar esto. Cuando se trata de la Inyección de Constructor, la ambigüedad es un olor de diseño. Básicamente estás diciendo: realmente no sé si me importa esta dependencia o no.

Claro, es probable que Unity lo descubra por usted, pero entonces estaría confiando en un comportamiento de contenedor específico en lugar de diseñar adecuadamente su API. Otros contenedores pueden tener un comportamiento diferente , por lo que si alguna vez elige migrar de Unity a un contenedor mejor, pueden producirse errores sutiles.

Es mucho más seguro escribir su código de manera amigable para DI, pero en contenedores .