Состояние сеанса с шаблонами MVP и Application Controller

Question

Я создал для разработки инфраструктуру MVP (пассивное представление) и решил использовать шаблон Application Controller для управления навигацией между представлениями. Он предназначен для интерфейсов WinForms, ASP.NET и WPF.

Хотя я не уверен на 100%, что эти технологии просмотра действительно могут быть заменены, на данный момент это моя цель, поэтому мой MVP-фреймворк довольно легкий.

Что я изо всех сил стараюсь вписать, так это концепция «делового разговора», которая требует, чтобы информация о состоянии либо (а) поддерживалась в течение всего срока действия представления, либо, более вероятно, (б) поддерживалась в нескольких представлениях для время существования варианта использования (деловой разговор). Я хочу, чтобы управление состоянием было частью структуры, так как я не хочу, чтобы разработчики беспокоились об этом. Все, что им нужно сделать, это «начать» разговор, «зарегистрировать» объекты, и фреймворк сделает остальное до «конца» разговора.

У кого-нибудь есть мысли (шаблоны), как вписать это в MVP? Я думал, что это может быть частью ответственности Application Controller (делегирование объекту Conversation Manager), поскольку он знает о текущем состоянии, чтобы отправить пользователя к следующему представлению .... но потом я подумал, что это может быть до Ведущий запускает и завершает беседу, а затем докладчики управляют беседами и объектами, зарегистрированными для этой беседы. К сожалению, это означает, что докладчики не могут быть использованы в разных разговорах ... поэтому эта идея не выглядит правильной.

Как видите, я не думаю, что есть простой ответ (и я некоторое время искал). Так у кого-нибудь еще есть мысли?

Answer 1

Классы, необходимые для поддержки делового разговора, должны находиться в докладчике, если он включает только пользовательский интерфейс. В противном случае он должен находиться в модели и контроллере от представления к докладчику и модели. С информацией о деловых разговорах течет другой путь. Я подозреваю, что это то, что может находиться только в Presenter.

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

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