Où dois-je mettre la création de la dépendance pour une classe Présentateur dans une architecture de vision passive?

Question

Je viens refactorisé une nouvelle classe de domaine d'une classe de présentateur mais je ne peux pas comprendre où instancier.

Cela fait partie d'un effort de refactoring en cours avec un plus grand projet héritage mal entretenu.

Le présentateur est en cours de création par l'événement OnLoad de la vue et la vue est passée comme paramètre dans le constructeur. Toutes les méthodes publiques du présentateur sont de retour et vide parameterless. Ils communiquent avec l'affichage à l'aide des propriétés publiques de la vue.

Le point de vue, étant essentiellement une forme humble dépend entièrement de la présentatrice pour tout.

Ceci est le modèle passif typique de vue et je voudrais continuer à y adhérer. Ce qui me amène à mon dilemme. Je dois créer une instance de mon nouvel objet de domaine pour le présentateur à utiliser.

• Si je passe à travers le constructeur alors la vue doit créer et gagne une dépendance inutile.
• Si je crée partout dans le présentateur, je ne peux pas le remplacer par un objet fantaisie dans mes tests unitaires.
• Si je fais une propriété publique du présentateur alors je présente une dépendance de l'ordre de création sur les méthodes de présentateur où il est utilisé et je l'ai toujours pas résolu quelle classe externe obtient la responsabilité de créer.

Je ne suis pas actuellement à l'aide des cadres d'injection de dépendance. Alors que je suis intéressé à l'aide d'un à l'avenir le code source reste beaucoup à fragile d'introduire un cadre tiers dans le mélange.

Je suis ouvert à toute suggestion.

Answer 1

J'ai trouvé une solution beaucoup plus simple. Voici un exemple de ma classe d'origine:

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

Je voulais passer ma nouvelle dépendance comme argument du constructeur, mais ne voulait pas ajouter cette dépendance à mon avis aussi. Enchaînement Constructor à la rescousse!

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

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

Maintenant, le code de production continue d'utiliser l'interface d'origine alors que les tests unitaires utilisent le nouveau passage dans simulacres à la fois la vue et la dépendance. Si le nombre de dépendances continue de croître refactoring sera nécessaire, mais pour l'avenir immédiat c'est une solution idéale.

Answer 2

Je l'ai déjà fait !!! Jetez un coup d'oeil ici mon dépôt . Mon choix constructeur est d'utiliser ... satisfaire les plus gourmands Je suis sûr que le présentateur est écoulé. Dans votre cas, vous pouvez fournir de la vue impl spécifique pour les dépendances.

vous amuser:)

Answer 3

Je vais pour un dépôt ou une usine pour l'instant. Il serait testable immédiatement. À l'avenir, vous pouvez remplacer sa mise en œuvre pour aller à une bibliothèque 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();
    }
}