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

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

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

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

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

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


person Graham Bunce    schedule 30.11.2009    source источник


Ответы (1)


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

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

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

person RS Conley    schedule 30.11.2009