Назовите минусы MVP (2/2)
Продолжим список классических проблем MVP:
• Раздутый интерфейс View
Если экран имеет много элементов и состояний, это приводит к тому, что в интерфейс View добавляется слишком много методов. Presenter будет использовать каждый метод для обновления маленькой части UI экрана.
Эта проблема решается разбиением экрана на несколько MVP компонентов, но иногда сложно найти правильный trade off.
• Сложно сохранять состояние
В правильной реализации MVP состояние хранится в Model. Пользователь делает действие → Presenter получает обновленную Model → Presenter обновляет View. Пользователь поворачивает экран → View пересоздается → Presenter инициализируется → Model возвращает закэшированные данные → Presenter обновляет View в том же состоянии.
В реальности помимо состояния бизнес модели существует состояние View. Например текст, введенный в EditText, но не отправленный на бэкенд, или состояние кастомной View (элемента UI, а не интерфейса MVP).
Если эти данные хранить в Model, то мы получаем раздутую модель, заботящуюся не о бизнес логике, а о логике отображения.
Если сохранять в Presenter, то нужно реализовать логику совмещения состояния View и состояния Model при инициализации. Дополнительно View должна обрабатывать метод onSaveInstanceState().
@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf' rel='nofollow'>Существует @czyrux/presenter-surviving-orientation-changes-with-loaders-6da6d86ffbbf' rel='nofollow'>множество подходов к решению этой проблемы, что фрагментирует MVP как паттерн и только увеличивает количество споров о том, какой способ реализации правильный.
#Architecture
Продолжим список классических проблем MVP:
• Раздутый интерфейс View
Если экран имеет много элементов и состояний, это приводит к тому, что в интерфейс View добавляется слишком много методов. Presenter будет использовать каждый метод для обновления маленькой части UI экрана.
Эта проблема решается разбиением экрана на несколько MVP компонентов, но иногда сложно найти правильный trade off.
• Сложно сохранять состояние
В правильной реализации MVP состояние хранится в Model. Пользователь делает действие → Presenter получает обновленную Model → Presenter обновляет View. Пользователь поворачивает экран → View пересоздается → Presenter инициализируется → Model возвращает закэшированные данные → Presenter обновляет View в том же состоянии.
В реальности помимо состояния бизнес модели существует состояние View. Например текст, введенный в EditText, но не отправленный на бэкенд, или состояние кастомной View (элемента UI, а не интерфейса MVP).
Если эти данные хранить в Model, то мы получаем раздутую модель, заботящуюся не о бизнес логике, а о логике отображения.
Если сохранять в Presenter, то нужно реализовать логику совмещения состояния View и состояния Model при инициализации. Дополнительно View должна обрабатывать метод onSaveInstanceState().
@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf' rel='nofollow'>Существует @czyrux/presenter-surviving-orientation-changes-with-loaders-6da6d86ffbbf' rel='nofollow'>множество подходов к решению этой проблемы, что фрагментирует MVP как паттерн и только увеличивает количество споров о том, какой способ реализации правильный.
#Architecture