Pregunta

Dada una clase con varios constructores - ¿cómo puedo saber resolver qué constructor de usar?

Tenga en cuenta 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 resolverá saber qué constructor de usar? ¿Y cómo puedo saber que utilizar el más adecuado? Digamos que tengo un recipiente con una IBar registrada - va a entender que se debe favorecer el constructor teniendo IBar? Y si puedo especificar una cadena también - va a utilizar el constructor (string, IBar)?

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

Y por favor, ignora el hecho de que probablemente sería más fácil si la clase acaba de tener un único constructor ...

¿Fue útil?

Solución

  

Cuando una clase de destino contiene más de un constructor, Unidad utilizará el que tiene el atributo InjectionConstructor aplicada. Si hay más de un constructor, y ninguno lleva el atributo InjectionConstructor, Unidad utilizará el constructor con la mayor cantidad de parámetros. Si hay más de una constructora (más de uno de los “más largo”, con el mismo número de parámetros), la unidad emitirá una excepción.

Tomado de enlace de texto

Otros consejos

Cuando se registra el tipo, puede especificar qué constructor de usar de esta manera:

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

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

  

Y por favor, ignora el hecho de que probablemente sería más fácil si la clase acaba de tener un único constructor ...

No puedo ignorar esto. Cuando se trata de constructor de inyección, ambigüedad es un olor diseño. Que son básicamente diciendo:. No se sabe muy bien si me importa acerca de esta dependencia o no

Por supuesto, la Unidad es probable que averiguarlo por ti, pero entonces se apoya en un comportamiento específico de contenedores en lugar de diseñar adecuadamente su API. Otros recipientes pueden tener un comportamiento diferente , por lo que si alguna vez decide migrar de la unidad a un contenedor mejor, se pueden producir errores sutiles.

Es mucho más seguro para escribir su código en un , pero envase de manera -agnostic.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top