Скромный Вид / MVP с WinForms и коллекцией UserControls

Question

Я занимаюсь рефакторингом приложения WinForms (.NET 4), которое использует TabControl для хранения UserControl - экземпляр UserControl создается в каждой вкладке TabPage, а конечный результат является редактором на каждой вкладке. Это редактирование набора элементов, которые в конечном итоге поступают в объект, редактируемый формой в целом.

В качестве примера структуры класса:

• class School
  • string Name
  • string Address
  • Коллекция Course с, каждое с несколькими соответствующими полями (Department, Name и т. Д.)

(На самом деле это не школьное приложение, но метафора работает.)

Визуально, набор UserControls управляет Course es, в то время как родительская форма обрабатывает информацию School.

Прямо сейчас у меня есть ведущий для формы / школы и ведущий для UserControl / курса, с представлением для каждого. Однако докладчик школы должен контролировать некоторую информацию для курсов. Например, параметры, выбранные для одного курса, ограничивают параметры в других. Модель School обрабатывает вычисления этого, но она должна добраться до ведущего курса.

У меня нет особого успеха в поиске примеров такого типа отношений в обсуждениях MVP, и я впервые использую подход MVP. Каковы хорошие варианты для обработки этого? Является ли уместным для ведущего школы иметь коллекцию ведущих курса для представления набора? Должен ли взгляд Школы содержать коллекцию взглядов Курсов? (Конечные пользовательские элементы управления должны в конечном итоге присоединяться к форме как-то и где-то, верно?)

Моими главными целями (что неудивительно) является повышение тестируемости и ремонтопригодности, и основными источниками в этом процессе до сих пор были серия "Диалоговое окно", посвященное скромности "Майкла Фезерса и серия" Создайте свою собственную CAB "Джереми Миллера.

Answer 1

Как я справляюсь с подобной ситуацией, родительский презентатор должен знать о дочерних презентаторах (как о зависимостях конструктора).

У каждого дочернего докладчика есть свое представление, поэтому в родительском докладчике моя логика выглядит примерно так:

Initialize () - инициализировать родительский - вызовите инициализацию для каждого дочернего презентатора (это для извлечения всех необходимых данных, КРОМЕ данных, которые в первую очередь показаны. Например, если у вас есть презентатор счетов, вам нужно откуда-то получить коллекцию клиентов, если у вас будет поле со списком клиентов, чтобы вы могли могу поменять это на счет) - встроить дочерние представления в родительское представление (родительский элемент обычно представляет собой форму, где дочерние элементы являются пользовательскими элементами управления)

затем после этого, обычно при загрузке родителя, с помощью некоторого метода LoadXXX, я также загружаю потомков. В вашем примере это будет что-то вроде

schoolPresenter.LoadSchool (школа)

, который, в свою очередь, загружал бы данные по всем докладчикам, например, загружал родительские элементы управления сведениями о школе, передавал коллекцию курсов докладчику курсов и т. Д. *

Одна мысль, которую я заметил, что это хорошо сделать, - это иметь метод Refresh () для каждого из этих докладчиков, который в основном знает, как загрузить себя в зависимости от текущего состояния. Может быть, у вас не может быть метода, подобного этому, для родительского докладчика, но простые докладчики работают нормально, как это, поэтому это означает, что в методе LoadSchool вы можете иметь что-то вроде

coursesPresenter.Courses = school.Courses; coursesPresenter.Refresh ();