¿Dónde pongo la creación de dependencias para una clase de presentador en una vista de la arquitectura pasiva?

Question

acabo de refactorizado a cabo una nueva clase de dominio de una clase presentador pero no puedo averiguar dónde instanciarlo.

Esto es parte de un esfuerzo continuo refactorización más grande con un proyecto heredado mantenimiento deficiente.

El presentador actualmente está siendo creado por evento OnLoad de la vista y la vista se pasa como un parámetro en el constructor. Todos los métodos públicos en el presentador son sin parámetros y volverá vacía. Se comunican con la vista utilizando propiedades públicas de la vista.

La vista, siendo esencialmente una forma humilde depende enteramente de la presentador para todo.

Este es el patrón típico Ver pasiva y me gustaría continuar a adherirse a ella. Lo que me lleva a mi dilema. Necesito crear una instancia de mi nuevo objeto de dominio para el presentador de usar.

• Si lo paso a través del constructor entonces la vista tiene que crearlo y gana una dependencia innecesaria.
• Si creo que en cualquier lugar dentro de la presentadora, no puedo reemplazarlo con un objeto de burla en mis pruebas de unidad.
• Si hago una propiedad pública del presentador a continuación les presento una dependencia de orden de creación de los métodos presentador donde se utiliza y todavía no se han resuelto lo de clase externo que asuma la responsabilidad de crearla.

No estoy usando actualmente cualquiera marcos de inyección de dependencia. Mientras me interesa es el uso de uno en el futuro el código fuente es todavía mucho frágil para introducir un marco tercero en la mezcla.

Estoy abierto a cualquier sugerencia.

Answer 1

he encontrado una solución mucho más simple. He aquí un ejemplo de mi clase original:

public Presenter(IView view)
{
    this.View = view;
}

quería pasar mi nueva dependencia como argumento del constructor, pero no quería añadir esta dependencia a mi punto de vista también. Constructor de encadenamiento al rescate!

public Presenter(IView view):this(view, new Dependency()){}

public Presenter(IView view, IDependency dependency)
{
    this.View = view;
    this.Dependency = dependency;
}

Ahora el código de producción continúa utilizando la interfaz original mientras que las pruebas de unidad utilizan el nuevo paso en burla tanto para la vista y la dependencia. Si el número de dependencias sigue creciendo, se necesitará algún refactorización pero para el futuro inmediato esta es una solución ideal.

Answer 2

Lo tengo ya hecho !!! Echar un vistazo aquí en mi repositorio . Mi elección aquí es utilizar el constructor ... satisfacer los más golosos Estoy seguro de que el presentador está arriba. En su caso se puede brindar a la vista impl específica para las dependencias.

divertirse:)

Answer 3

Me gustaría ir a un depósito o una fábrica, por ahora. Sería comprobable inmediatamente. En el futuro, puede reemplazar su implementación a ir a una biblioteca DI.

public class DomainObjectsRepository
{
    /// <summary>
    /// can not be instantiated, use <see cref="Instance"/> instead.
    /// </summary>
    protected DomainObjectsRepository()
    {

    }

    static DomainObjectsRepository()
    {
        Instance = new DomainObjectsRepository();
    }

    public static DomainObjectsRepository Instance { get; set; }


    public virtual ICustomerDao GetCustomerDao()
    {
        return new CustomerDao();
    }
}

public class DomainObjectsRepositoryMock : DomainObjectsRepository
{
    public override ICustomerDao GetCustomerDao()
    {
        return new CustomerDaoMock();
    }
}