Примеры сложных контроллеров для winforms

Question

Извините, если об этом уже спрашивали, но я не смог найти помощь.

Мне было интересно, есть ли у кого-нибудь хорошие примеры сложных winforms, созданных с использованием шаблона MVP контролирующего контроллера. Я прочитал много примеров, но на самом деле они просты и имеют дело только с одной формой и одной моделью.

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

Скажи, что у меня есть такой интерфейс: альтернативный текст http://img12.imageshack.us/img12/2683/layoutcroped.jpg

Извините за изворотливый макет пользовательского интерфейса. в основном каждый пользовательский элемент управления имеет свой собственный презентатор и объект модального слоя.

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

У меня вопрос: передать ли модель пользовательскому элементу управления 2 через интерфейс просмотра или в презентатор?

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

EDIT: Я сделал два разных, я думаю, я мог бы сделать это:

• Ex1 альтернативный текст http://img123.imageshack.us/img123/4513/exampleone.jpg

и

• Ex2 альтернативный текст http://img268.imageshack.us/img268/2320/exampletwo.jpg

Я думаю, что Ex1 лучше, так как он все еще оставляет за собой ответственность докладчиков. Делать что хотят.

Что ты думаешь?

Спасибо.

Answer 1

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

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

Так, например, ваш UserControl1 отправляет данные в модель через презентатор, а модель затем уведомляет все зарегистрированные представления об изменениях (отправляет их в модель для соответствующего обновления).

Надеюсь, это поможет.

Answer 2

Способ, которым я бы подошел к этому, основан на подходе, ориентированном на событие, публикация / подписка.

Шаблон выглядит примерно так:

1. Пользователь, нажимающий кнопку «Редактировать» в первом представлении, запускает событие (вы можете назвать его командой) с одним параметром (идентификатор, значение текстового поля в данном случае). Назовите событие «EditRequested», скажем. Это «публикация» события, рассказывающая всем, кто хочет знать, что это произошло, и подробности. Фактическая публикация может быть выполнена в контроллере / докладчике.

2. Контроллер / презентатор для второго просмотра прослушивает указанное выше событие и, когда событие запускается, действует соответственно, загружая данные и переключаясь в режим редактирования, используя параметр события (ID). Это часть шаблона подписки.

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

Answer 3

У нас были серьезные проблемы с этим предметом. Сначала мы предположили, что первое представление отвечает за создание и настройку второго представления, а первое средство презентации - за создание и настройку второго. Это решение было плохим по многим причинам. Прежде всего, второй вид был настроен двумя другими объектами (первый вид и второй докладчик). Вторым недостатком было объединение взглядов и логическая ответственность за представление.

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

Answer 4

Я думаю исходя из того, что вы говорите, что вам лучше подумать о том, чтобы один докладчик посвятил (и контролировал) то, что необходимо для конкретной презентации (т. Е. "Сбор информации о клиенте") ). Затем подумайте о том, чтобы передать модель (или ее фасад, если есть достаточная сложность) в этого предъявителя на строительстве.

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

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

Я не знаю ни одного примера, который позволил бы реализовать сценарий, который вы начинаете раскрывать, но я бы сосредоточился на различных примерах mvp на сайте Фаулера и посмотрел серию Джереми Миллера «Построй свою собственную кабину». Оба будут немного разочарованы, поскольку ни один из них не быстро решит ваши проблемы, но оба предоставят понимание аспектов этой широкой темы.

Надеюсь, это поможет! Berryl