Onde posso colocar a criação de dependência para uma classe Presenter em uma arquitetura Passive View?

Question

Eu apenas reformulado uma nova classe de domínio de uma classe apresentador, mas não consigo descobrir onde instanciá-lo.

Esta é parte de um esforço de refatoração em curso maior, com um projeto de legado mal conservados.

O Presenter está sendo criado por OnLoad evento da vista ea vista é passado como um parâmetro no construtor. Todos os métodos públicos do apresentador são parâmetros e retornar void. Eles se comunicam com o ponto de vista usando propriedades públicas do ponto de vista.

A vista, sendo essencialmente uma forma humilde depende inteiramente do apresentador para tudo.

Este é o típico padrão Passive View e eu gostaria de continuar a aderir a ela. O que me leva ao meu dilema. Eu preciso criar uma instância de meu novo objeto de domínio para o apresentador para uso.

• Se eu passá-lo através do construtor, em seguida, a visão tem que criá-lo e ganha uma dependência desnecessária.
• Se eu criá-lo em qualquer lugar dentro do apresentador, não pode substituí-lo com um objeto fictício em meus testes de unidade.
• Se eu torná-lo uma propriedade pública do apresentador então eu introduzir uma dependência ordem de criação sobre os métodos de apresentador onde ele é usado e eu ainda não tenham resolvido o classe externa recebe a responsabilidade de criá-la.

Eu não estou usando atualmente algum frameworks de injeção de dependência. Enquanto eu estou interessado lo usando um no futuro o código fonte ainda muito a frágil para introduzir um quadro de terceiros na mistura.

Estou aberto a todas as sugestões.

Answer 1

Eu encontrei uma solução muito mais simples. Aqui está um exemplo da minha classe original:

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

Eu queria passar a minha nova dependência como um argumento do construtor, mas não deseja adicionar essa dependência à minha vista bem. Construtor encadeamento para o resgate!

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

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

Agora, o código de produção continua a usar a interface original, enquanto os testes de unidade usar o novo passando em simulações tanto para a vista e dependência. Se o número de dependências continua a crescer serão necessários alguns refatoração, mas para o futuro imediato esta é uma solução ideal.

Answer 2

Eu já feito !!! Dê uma olhada aqui na meu repositório . Minha escolha aqui é usar construtor ... satisfazendo a greediest Tenho certeza de que o apresentador é para cima. No seu caso, você pode fornecer a partir impl específico vista para dependências.

se divertir:)

Answer 3

Eu iria para um repositório ou uma fábrica para agora. Seria testável imediatamente. No futuro, você pode substituir a sua implementação para ir a uma biblioteca de 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();
    }
}