Где я могу разместить создание зависимостей для класса Presenter в архитектуре пассивного представления? - PullRequest
Новая
       12

Где я могу разместить создание зависимостей для класса Presenter в архитектуре пассивного представления?

4 голосов
/ 11 мая 2009

Я только что произвел рефакторинг нового класса домена из класса презентатора, но не могу понять, где его создать.

Это часть более масштабной работы по рефакторингу с плохо поддерживаемым устаревшим проектом.

Presenter в настоящее время создается с помощью события OnLoad представления, и представление передается в качестве параметра в конструкторе. Все открытые методы в презентере не имеют параметров и возвращают void. Они взаимодействуют с представлением, используя общие свойства представления.

Вид, являющийся по сути скромной формой, полностью зависит от ведущего во всем.

Это типичный шаблон пассивного просмотра, и я хотел бы продолжать придерживаться его. Что приводит меня к моей дилемме. Мне нужно создать экземпляр моего нового объекта домена для использования докладчиком.

  • Если я пропущу его через конструктор, то представление должно его создать и получить ненужную зависимость.
  • Если я создам его где-нибудь в презентере, я не могу заменить его фиктивным объектом в своих модульных тестах.
  • Если я сделаю это публичным свойством презентатора, я введу зависимость порядка создания от методов презентатора, где он используется, и я до сих пор не решил, какой внешний класс отвечает за его создание.

В настоящее время я не использую никаких структур внедрения зависимостей. Хотя я заинтересован в его использовании в будущем, исходный код все еще очень хрупок, чтобы внедрить стороннюю платформу.

Я открыт для любых предложений.

Ответы [ 3 ]

2 голосов
/ 11 мая 2009

Я уже сделал это !!! Загляните сюда, в мой репозиторий . Мой выбор здесь - использовать конструктор ... удовлетворяющий самое жадное Я уверен, что ведущий Up. В вашем случае вы можете предоставить из вида определенный impl для зависимостей.

веселись :) 1005 *

1 голос
/ 12 мая 2009

Я нашел гораздо более простое решение. Вот пример моего оригинального класса: 

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

Я хотел передать свою новую зависимость в качестве аргумента конструктора, но не хотел также добавлять эту зависимость в свое представление. Конструктор приковывает на помощь! 

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

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

Теперь производственный код продолжает использовать исходный интерфейс, в то время как модульные тесты используют новый, передавая mocks для представления и зависимости. Если число зависимостей будет продолжать расти, потребуется рефакторинг, но в ближайшем будущем это идеальное решение.

0 голосов
/ 12 мая 2009

Я бы сейчас пошел в хранилище или на фабрику. Это будет проверено немедленно. В будущем вы можете заменить его реализацию, чтобы перейти к библиотеке 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();
    }
}
...