Wo platziere ich Abhängigkeits Erstellung für eine Presenter-Klasse in einer Passive View-Architektur?

Question

Ich habe gerade eine neue Domain-Klasse aus einer Präsentator Klasse Refactoring, aber ich kann nicht herausfinden, wo es zu instanziieren.

Dies ist Teil einer größeren laufenden Refactoring Anstrengung mit einem schlecht gewarteten Legacy Projekt.

Der Moderator wird derzeit von der OnLoad Ereignisse Ansicht erstellt werden und die Ansicht wird als Parameter in dem Konstruktor übergeben. Alle öffentlichen Methoden in der Präsentator sind parameterlos und leer kommen. Sie kommunizieren mit der Ansicht mit dem öffentlichen Eigenschaften der Ansicht.

Die Ansicht, wobei im Wesentlichen eine bescheidene Form hängt ganz von dem Moderator für alles.

Dies ist die typische Passive Ansicht Muster und ich möchte es auch weiterhin zu halten. Das bringt mich zu meinem Dilemma. Ich brauche eine Instanz meiner neuen Domain-Objekt für den Vortragenden schaffen zu verwenden.

• Wenn ich es durch den Konstruktor übergeben dann die Aussicht hat, es zu schaffen und gewinnt eine unnötige Abhängigkeit.
• Wenn ich es irgendwo innerhalb des Moderators schaffen, ich kann es nicht ersetzen mit einem Mock-Objekt in meinen Unit-Tests.
• Wenn ich es ein öffentliches Eigentum des Moderators mache dann ich eine Schöpfung um die Abhängigkeit von den Präsentator Methoden einzuführen, in denen es verwendet wird, und ich habe immer noch nicht gelöst, was externe Klasse Verantwortung wird es für die Erstellung.

Ich bin derzeit nicht mit beliebiger Dependency Injection-Frameworks. Während ich bin interessiert es eine Verwendung in der Zukunft der Quellcode noch viel zu zerbrechlich ist, eine dritte Partei Rahmen in die Mischung einzuführen.

Ich bin offen für alle Vorschläge.

Answer 1

fand ich eine viel einfachere Lösung. Hier ist ein Beispiel von meiner ursprünglichen Klasse:

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

Ich wollte meine neue Abhängigkeit als Konstruktor Argument übergeben, wollte aber nicht so gut, diese Abhängigkeit zu meiner Ansicht hinzuzufügen. Konstruktorverkettung zur Rettung!

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

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

Nun ist der Produktionscode weiterhin die Original-Schnittstelle, während die Unit-Tests die neuen in Mocks sowohl für die Ansicht und die Abhängigkeit vorbei verwenden zu verwenden. Wenn die Anzahl der Abhängigkeiten weiterhin einige Refactoring wachsen wird benötigt, aber für die unmittelbare Zukunft ist dies eine ideale Lösung.

Answer 2

Ich habe es schon getan !!! Werfen Sie einen Blick hier in mein Repository . Meine Auswahl hier ist Konstruktor zu verwenden ... Erfüllen der greediest Ich bin sicher, dass Moderator Up ist. In Ihrem Fall können Sie aus Sicht spezifischen impl für Abhängigkeiten schaffen.

hat Spaß:)

Answer 3

würde ich für ein Endlager oder eine Fabrik für jetzt gehen. Es wäre sofort überprüfbar. In Zukunft können Sie die Implementierung ersetzen zu einer DI-Bibliothek zu gehen.

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();
    }
}