SimpleIOC: ¿puede proporcionar una nueva instancia cada vez requerida?

Question

Hasta donde entiendo, SimpleIOC utiliza el método GetInstance para recuperar una instancia de una clase que está registrada. Si la instancia no existe, la creará. Sin embargo, esta instancia se almacena en caché y siempre se recupera, lo que imita el patrón Singleton.

Mi pensamiento es que no hay necesidad de mantener una instancia de ViewModel en una memoria si existe una pequeña posibilidad de que este Modelo ViewModel se necesite dos veces, por lo que me gustaría crear una nueva instancia de ella cada vez que sea necesario. Si tenemos una fábrica para ViewModels, tendremos una propiedad como esta:

public MyViewMOdel MyViewModel
{
    get { return SimpleIoc.Default.GetInstance<MyViewModel>(); }
}

Este usa el patrón Singleton, que creo que no es la mejor práctica en todos los casos. Para eludir este problema, hago esto:

public MyViewModel MyViewModel
{
    get { return new MyViewModel(SimpleIoc.Default.GetInstance<ISomeInterface>()); }
}

Este tiene una desventaja de que si alguna vez cambio un constructor para myViewModel, también tendré que actualizar esta propiedad. No es gran cosa, pero aún así hay algún tipo de dependencia.

¿Cómo manejas este escenario y hay algo que me estoy perdiendo? y por qué se decidió no devolverse la instancia no compartida.

Y otra pregunta es, en la sesión de buceo profunda de MVVM, Laurent utiliza el método GetInstance justo después de registrar un model de vista particular, para, como él dice, asegurarse de que ya haya una instancia de este modelado en el contenedor. ¿Por qué es exactamente necesario esto? Si está obteniendo un ViewModel a través de ViewModEllocator, lo creará cuando sea necesario. Entonces, ¿por qué querría que se hayan creado por adelantado?

Answer 1

Puede obtener una instancia diferente cada vez pasando una clave diferente al método GetInstance. Sin embargo, las instancias se almacenarán en caché, por lo que si no desea mantenerlas en el caché, deberá llamar a la no registro con la clave correspondiente.

En la demostración, estaba creando la VM por adelantado porque el MainVM estaba enviando mensajes al SecondAryVM. Dado que el registro en el Messenger se realiza en el constructor de SecondAyVM, debe crearse antes de que pueda comenzar a recibir mensajes. El mensajero es excelente porque está muy desacoplado, pero es uno de estos casos en los que debe hacer un trabajo adicional para compensar el desacoplamiento: el SecondAyVM es el objetivo de los mensajes a pesar de que el MainVM no tiene ninguna referencia a él.

Espero que tenga sentido. Saludos, Laurent

Answer 2

SimpleIOC es lo que es ... un contenedor de COI simple. Tendrá algunos comunicados cortos ... pero no estás vinculado a él, siempre puedes usar otro contenedor ICO (por ejemplo, unidad, autofac, castillo, ...).

Como Estados de laurent modeló su simplisioc en este contenedor. El también menciona este contenedor Como fuente de su inspiración.

Sin embargo, recuerda No está obligado a usar un contenedor secífico con MVVM. En varios de mis proyectos utilicé Unity, pero cualquier otro contenedor del COI será igualmente bien, es una cuestión de requisitos, preferencias del cliente y, si todo lo demás falla, simplemente viejo personal entusiasmo.

Answer 3

Después de la lucha libre con SimpleIOC para proporcionar nuevas instancias cada vez que se solicita un tipo específico y descubrir que esta característica no se implementa (el método basado en la clave aceptado anteriormente no se ajusta a los escenarios en los que desea decir, realizar una operación de base de datos y lanzar la conexión Lejos cada vez), se me ocurrió una solución relativamente decente que combina el COI con el patrón de fábrica: cree una clase que asuma la responsabilidad de instanciar nuevas instancias de cierto tipo a través de una función:

class MyObjectFactory: IMyObjectFactory
{
    public MyObject CreateObject()
    {
        return new MyObject();
    }
}

Crea la interfaz para la clase de fábrica MyObject:

public interface IMyObjectFactory
{
    MyObject CreateObject();
}

Luego configure el contenedor IOC para proporcionar la fábrica a cualquier clases que use instancias de MyObject:

SimpleIoc.Default.Register<IMyObjectFactory, MyObjectFactory>();

Ahora, cualquier clase que requiera una nueva instancia de MyObject declararía su requisito MyObjectFactory (en lugar de requisito de MyObject) en el constructor para la inyección del constructor:

public class MyObjectUser
{
    MyObject _myObject;
    public MyObjectUser(IMyObjectFactory factory)
    {
        _myObject = factory.CreateObject();
    }
}

De esta manera, creo que no estás obligado por las limitaciones del patrón de fábrica y tienes todos los beneficios de los contenedores del COI y la inyección de constructor, eludiendo también la limitación de SimpleioC.