Первым делом стоит обратиться к
описанию[
T] MVP от Мартина Фаулера.
Фаулер сразу оперирует поверх GUI на базе модели форм и элементов, т.е. рассматривает твой конкретный случай.
Модель форм и элементов оперирует событиями элементов для интерпретации пользовательского ввода. Согласно Фаулеру, обработку этих событий стоит передать презентеру. Презентер в этом случае обрабатывает пользовательский ввод, передает его модели и собирает с модели обновленные данные для передачи в вид. Внутренние данные вида, которые не предназначены для модели, должен обрабатывать тоже презентер, после чего все так же передавать в вид.
Вид должен только отображать данные модели и отсылать в презентер сигналы пользовательского ввода.
Что будет если сделать по-другому. Например, как описано у тебя в вопросе. Сейчас у себя ты потерял гибкость и буквально разрушил абстракцию презентера. Если презентер вдруг потребуется сделать композитным (например, выбирать видимые и доступные для ввода элементы вида), ты упрешься в рефакторинг и вида, и презентера. Это отсрочит реализацию композитности логики презентера. Если потребуется держать одновременно несколько видов для одной модели, тебе придется как-то внедрять Change Propagation. В рядовом MVP за это отвечает презентер, а у тебя выйдет что вид должен подписываться на уведомление, что характерно уже не для MVP, а для MVC.
MVP, как и MVC, является архитектурным шаблоном. Такие шаблоны находятся на самом верхнем уровне пирамиды отношений шаблонов. Это говорит о том, что уже просто реализация MVC/MVP в лоб в коде является нежелательной. MVC/MVP задают для кода UI строгое разделение по функциональности: ввод данных, процессинг и вывод данных. Вот что должно явно присутствовать в твоем коде, вот что стоит реализовать с использованием шаблонов дизайна и идиом разработки. Например, презентер или контроллер может быть сформирован на базе Rx и быть полностью децентрализованным, но при этом качественно выполнять свои функции. А вид и вовсе может быть data-driven объектом, т.е. не иметь даже минимальной личной логики.
Каждый архитектурный шаблон, помимо легкой поддержки, сформирован из расчета на изначальную простоту, возможность стыковки с другими архитектурными шаблонами и потенциальную расширяемость.
В результате, заложив изначально слабую реализацию MVP, дальнейшими действиями ты рискуешь размыть границы элементов архитектуры, снизить прозрачность реализации для понимания другими людьми и усложнить поддержку этого кода.
Простой
