Как вы перемещаетесь между представлениями в MVP, используя C # WinForms?

Question

Как я понимаю, когда мы используем MVP, мы перемещаем всю логику представления в Presenter. Но мы не хотим, чтобы докладчик знал о реализации представления, так как мы можем перейти к другому экрану в приложении? Как вы управляете потоком приложений в вашем реальном приложении?

Answer 1

Используя некоторый интерфейс навигатора, например:

interface INavigator
{
    void MoveTo (string screenName);
    void MoveTo (string screenName, NavigationParameters parameters);
}

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

Вы можете настроить отображение между именами экранов и фактическими классами форм, определенными в конфигурации.

Answer 2

Я предполагаю, что вы имеете в виду другой экран, который имеет свою MVP-пару?

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

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

Answer 3

Это метод в представлении. Таким образом, у вас будет абстрактный метод, такой как ShowCustomerForm (), например, и реализация для WinForms будет CustomerForm.Show (или чем-то еще в WinForms), а в WebForms это будет Response.Redirict (CustomerForm.aspx).

Answer 4

Мы делаем это, используя то, что Леннерт называет координатором (мы называем это контроллером рабочего процесса). Я пришел из веб-разработки на Java, и идея была формой ApplicactionController. Я столкнулся с некоторыми проблемами с этим, workflowcontroller запускает команду. Каждая команда представляет рабочий процесс или ряд связанных шагов (таким образом, называется workflowcontroller). Flowcontroller управляет навигацией между командами, а у flowcontroller есть навигатор, который перемещается между шагами. У каждого шага есть событие финиша (к которому подключается докладчик) и метод NextStep, который мы используем для перехода к следующему шагу. Наш worflowcontroller тесно связан с меню, поэтому мы можем перемещаться между различными рабочими процессами. Шаги устанавливают связь между представлением и докладчиками. У нас нет никакой конфигурации, и мы встроили логику, которая устанавливает следующий шаг для выполнения, в метод с именем NextStep. Он находится в производстве, но я не очень доволен этим. Слишком много деталей, чтобы попасть сюда. Я думал о том, чтобы перейти к чему-то более ориентированному на события. Мы используем шину сообщений для всех остальных наших коммуникаций, и я хотел бы перейти к использованию этого для навигации между экранами. Я не знаю, было бы это полезно или нет. наши экраны по большей части состоят из последовательных рабочих процессов.