Dove metto la creazione di dipendenza per una classe Presenter in una vista architettura passiva?

Question

Ho appena refactoring una nuova classe di dominio da una classe presentatore, ma non riesco a capire dove creare un'istanza di esso.

Questa è parte di un più ampio sforzo refactoring in corso con un progetto legacy scarsa manutenzione.

Il Presenter è in fase creato da evento OnLoad della vista e la vista è passato come parametro nel costruttore. Tutti i metodi pubblici del presentatore sono senza parametri e restituiscono vuoto. Comunicano con la vista utilizzando le proprietà pubbliche della vista.

La vista, essendo essenzialmente una forma modesto dipende interamente il presentatore per tutto.

Questo è il tipico Vista modello passivo e mi piacerebbe continuare ad aderire ad esso. Il che mi porta al mio dilemma. Ho bisogno di creare un'istanza del mio nuovo oggetto di dominio per il presentatore da utilizzare.

• Se mi passa attraverso il costruttore poi la vista deve creare e guadagna una dipendenza non necessaria.
• Se creo ovunque all'interno del presentatore, non riesco a sostituirlo con un oggetto fittizio nel mio test di unità.
• Se faccio una proprietà pubblica del presentatore poi introduco una dipendenza ordine di creazione sui metodi presentatore in cui viene utilizzato e non ho ancora risolto quale classe esterna ottiene la responsabilità di creare esso.

Non sto attualmente utilizzando uno dei quadri iniezione di dipendenza. Mentre io sono interessato utilizzando uno in futuro il codice sorgente è ancora molto da fragile per introdurre un quadro di terze parti nel mix.

Sono aperto a qualsiasi suggerimento.

Answer 1

Ho trovato una soluzione molto più semplice. Ecco un esempio della mia classe originale:

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

ho voluto passare la mia nuova dipendenza come un argomento del costruttore, ma non volevo aggiungere questa dipendenza al mio punto di vista come bene. Constructor concatenamento in soccorso!

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

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

Ora il codice di produzione continua a utilizzare l'interfaccia originale mentre i test di unità usa il nuovo passando mock sia per la vista e dipendenza. Se il numero di dipendenze continua a crescere sarà necessario un po 'di refactoring, ma per l'immediato futuro si tratta di una soluzione ideale.

Answer 2

L'ho già fatto !!! Date un'occhiata qui a mio repository . La mia scelta è quello di utilizzare il costruttore ... soddisfare i più golosi sono sicuro che il presentatore è Up. Nel tuo caso è possibile fornire da impl specifica vista per le dipendenze.

divertirsi:)

Answer 3

mi piacerebbe andare per un repository o una fabbrica, per ora. Sarebbe verificabile immediatamente. In futuro, è possibile sostituire la sua attuazione di andare in una libreria 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();
    }
}