¿Hay un patrón para inicializar objetos creados a través de un contenedor DI

Por lo general, cuando se encuentra con esta situación, debe revisar su diseño y determinar si está mezclando sus objetos con estado/datos con sus servicios pure. En la mayoría de los casos (no en todos), querrá mantener estos dos tipos de objetos separados.

Si necesita que se pase un parámetro específico del contexto en el constructor, una opción es crear una fábrica que resuelva sus dependencias de servicio a través del constructor y tome su parámetro en tiempo de ejecución como parámetro de la creación() método (o Generate (), Build () o como llames tus métodos de fábrica).

Tener setters o un método Initialize() generalmente se cree que es un mal diseño, ya que necesita "recordar" llamarlos y asegurarse de que no abran demasiado el estado de su implementación (es decir, ¿qué es evitar que alguien vuelva a llamar a initialize o al setter?).

También me he encontrado con esta situación algunas veces en entornos donde estoy creando dinámicamente objetos ViewModel basados en objetos de modelo (delineados muy bien por este otro post de Stackoverflow).

Me gustó cómo la extensión Ninject que le permite crear dinámicamente fábricas basadas en interfaces:

Bind<IMyFactory>().ToFactory();

No pude encontrar ninguna funcionalidad similar directamente en Unity ; así que escribí mi propia extensión a la IUnityContainer que le permite registrar fábricas que crearán nuevos objetos basados en datos de objetos existentes esencialmente mapeando desde una jerarquía de tipos a una jerarquía de tipos diferente: UnityMappingFactory@GitHub

Con un objetivo de simplicidad y legibilidad, terminé con una extensión que le permite especificar directamente las asignaciones sin declarar clases de fábrica individuales o interfaces (un ahorro de tiempo real). Solo tienes que añadir las asignaciones justo donde registre las clases durante el proceso normal de bootstrapping...

//make sure to register the output...
container.RegisterType<IImageWidgetViewModel, ImageWidgetViewModel>();
container.RegisterType<ITextWidgetViewModel, TextWidgetViewModel>();

//define the mapping between different class hierarchies...
container.RegisterFactory<IWidget, IWidgetViewModel>()
.AddMap<IImageWidget, IImageWidgetViewModel>()
.AddMap<ITextWidget, ITextWidgetViewModel>();

Luego simplemente declare la interfaz de fábrica de asignación en el constructor para CI y use su método Create()...

public ImageWidgetViewModel(IImageWidget widget, IAnotherDependency d) { }

public TextWidgetViewModel(ITextWidget widget) { }

public ContainerViewModel(object data, IFactory<IWidget, IWidgetViewModel> factory)
{
    IList<IWidgetViewModel> children = new List<IWidgetViewModel>();
    foreach (IWidget w in data.Widgets)
        children.Add(factory.Create(w));
}

Como una ventaja adicional, cualquier dependencia adicional en el constructor de las clases asignadas también se resolverá durante la creación del objeto.

Obviamente, esto no resolverá todos los problemas, pero me ha servido bastante bien hasta ahora, así que pensé que debería compartirlo. Hay más documentación en el sitio del proyecto en GitHub.

No puedo responder con terminología específica de Unity, pero parece que estás aprendiendo sobre la inyección de dependencias. Si es así, le insto a que lea la breve, clara y llena de información guía del usuario para Ninject.

Esto le guiará a través de las diversas opciones que tiene al usar DI, y cómo dar cuenta de los problemas específicos que enfrentará en el camino. En su caso, lo más probable es que desee usar el contenedor DI para crear instancias de sus objetos, y hacer que ese objeto obtenga una referencia a cada una de sus dependencias a través del constructor.

El tutorial también detalla cómo anotar métodos, propiedades e incluso parámetros usando atributos para distinguirlos en tiempo de ejecución.

Incluso si no usas Ninject, el tutorial te dará los conceptos y la terminología de la funcionalidad que se adapte a tu propósito, y deberías ser capaz de asignar ese conocimiento a Unity u otros frameworks DI (o convencerte de que le des una oportunidad a Ninject).

Creo que lo resolví y se siente bastante saludable, por lo que debe ser medio correcto:))

Divido IMyIntf en interfaces "getter" y "setter". Entonces:

interface IMyIntf {
  string RunTimeParam { get; }
}


interface IMyIntfSetter {
  void Initialize(string runTimeParam);
  IMyIntf MyIntf {get; }
}

Luego la implementación:

class MyIntfImpl : IMyIntf, IMyIntfSetter {
  string _runTimeParam;

  void Initialize(string runTimeParam) {
    _runTimeParam = runTimeParam;
  }

  string RunTimeParam { get; }

  IMyIntf MyIntf {get {return this;} }
}

//Unity configuration:
//Only the setter is mapped to the implementation.
container.RegisterType<IMyIntfSetter, MyIntfImpl>();
//To retrieve an instance of IMyIntf:
//1. create the setter
IMyIntfSetter setter = container.Resolve<IMyIntfSetter>();
//2. Init it
setter.Initialize("someparam");
//3. Use the IMyIntf accessor
IMyIntf intf = setter.MyIntf;

IMyIntfSetter.Initialize() todavía se puede llamar varias veces, pero usando bits de Service Locator paradigm podemos envolverlo bastante bien para que IMyIntfSetter sea casi una interfaz interna que es distinta de IMyIntf.