Я думаю, что вы абсолютно правы, когда говорите, что представление хранит состояние представления в MVP: это просто способ, которым «проблемы разделены» в MVP. В «чистом MVP» состояние просмотра сохраняется в представлении, а не в презентере. Докладчик может запросить представление о его состоянии, используя методы, предоставляемые интерфейсом представления.
Сохранение состояния в докладчике сделает вашего докладчика гибридом между моделью презентации и докладчиком. Будьте прагматичны и не перестраивайте свое полное приложение, если вы иногда сохраняете некоторое состояние просмотра в докладчике.
Просто помните об общих мотивах использования паттернов PM или MVP.
В веб-статье eeaDev Фаулера о модели презентации он заявляет:
Модель представления - это шаблон, который
вытягивает поведение презентации из
Посмотреть. Таким образом, это альтернатива
Контролирующему контроллеру и пассиву
Посмотреть. Это полезно для того, чтобы позволить вам
тестирование без интерфейса, поддержка некоторых
форма множественного просмотра и разделения
проблем, которые могут облегчить
разработать пользовательский интерфейс.
Фаулер продолжает:
По сравнению с пассивным просмотром и
Контролер, Презентация
Модель позволяет писать логику, которая
полностью независим от взглядов
используется для отображения. Вам также не нужно полагаться на представление для сохранения состояния.
Недостатком является то, что вам нужно
механизм синхронизации между
презентационная модель и вид.
Я не согласен с утверждением, которое вы цитируете в своем вопросе:
Одной из [проблем MVP] является сохранение состояния View.
Это не проблема: это выбор. IMO Fowler не упоминает об этом «состоянии постоянства представления» как мотивация использовать модель представления вместо MVP, будь то Контролирующий контроллер или Пассивное представление .
Я не совсем уверен, что Фаулер с "хранить состояние" означает постоянство в смысле "через время жизни приложения". Но независимо от того, дело в том, что это выбор с компромиссом: когда вы используете Presentation Model вместо MVP, вы получаете
- лучшая тестируемость состояния просмотра
- независимость просмотра от (сохранения) состояния просмотра
- «Программист» может создавать PM, а «Дизайнер пользовательского интерфейса» может отдельно работать над представлением
за счет
- необходимость синхронизации представления с моделью презентации
Обратите внимание, что последние "затраты" в настоящее время могут быть меньше, чем на момент написания Фаулером (2006), из-за современных методов синхронизации пользовательского интерфейса, таких как привязка данных .NET.