Где хранить состояние в архитектуре MVP

Question

В других связанных с MVP вопросах SO люди говорят о том, что Presenter хранит информацию о состоянии (может быть состояние сеанса или состояние пользовательского интерфейса). Что меня интересует, так это то, что состояние - это, по сути, «временные данные», и цель модели заключается в инкапсуляции доступа к данным, нельзя ли сохранить состояние внутри модели? Существуют ли какие-либо практические правила или плюсы / минусы в отношении сохранения состояния в Presenter и Model? Обязывает ли шаблон MVP использование докладчика?

Answer 1

Цель модели - не инкапсулировать доступ к данным, а предоставить представление (модель) вашего домена, каким бы оно ни было.Иногда доступ к данным включается как часть модели (например, с доступом к данным в стиле Active Record ), но чаще всего он является отдельным.Например, когда я выполнял MVP в настольных приложениях, докладчик извлекал модель из базы данных напрямую или с помощью репозитория - модель не имела ничего общего с доступом к данным.* Где хранить состояние, относящееся к представлению, является серой областью, и зависит от того, какой тип приложения вы используете - для настольных приложений это намного проще, поскольку вы можете просто сохранить его в презентере, для веб-приложенийнемного сложнее.Вы можете рассмотреть отдельную модель для представления, которая может включать или не включать базовую модель (как в ViewModel в шаблоне MVVM , популярном в разработке .Net WPF).

Answer 2

Если состояние напрямую связано с представлением, тогда докладчик является подходящим местом.

Если нет, то Модель, вероятно, является подходящим местом, но в некоторых случаях может подойти Ведущий.

Ключевым моментом здесь является то, что View и Presenter концептуально связаны друг с другом - в то время как Presenter может не знать о конкретном View, обычно ему нужно будет предоставлять конкретные данные для View, который он обслуживает.