Comments 19
Не хочу разводить споров, но не стоит так категорично относиться к MVP
Видимо вы не правильно готовите MVP.
Просто пробегусь по минусам:
Создайте общий view и используйте его для тех случаев, когда вам не нужны лишние view или конструкции повторяются
Презентер завязан на интерфейс VIew, а не на VIEW в понимании компонента андроида. Презентер не касается визуальной составляющей, а общается через интерфейсы, которые вообще привязаны к визуальной составляющей только в одностороннем порядке. Это позволяет вам использовать один презентер для разных активностей имеющих набор общих данных но разную визуальную составляющую
Такое может возникнуть например в случае, когда мы открыли activity, и потом резко повернули экран, чтобы активити пересоздалось. Тогда используйте Observable и получайте уже загруженные данные.
Вот MVVM на мой взгляд как-раз и получается чрезмерно перегруженным и уж очень сильно зависит от VIEW в понимании визуальной составляющей. В своем примере вы приводите пример obsrvable, но о минусах MVVM не упоминаете ) Исходя только из приведенного примера MVVM можно вообще использовать котлиновские callback.
Возможно просто я не умею готовить MVVM ;)
Видимо вы не правильно готовите MVP.
Просто пробегусь по минусам:
Приходится создавать интерфейс View под каждый экран. На больших проектах будем иметь много лишнего кода и файлов, которые затрудняют навигацию по пакетам.
Создайте общий view и используйте его для тех случаев, когда вам не нужны лишние view или конструкции повторяются
Presenter сложно переиспользовать, так как он завязан на View, а она может иметь специфичные методы.
Презентер завязан на интерфейс VIew, а не на VIEW в понимании компонента андроида. Презентер не касается визуальной составляющей, а общается через интерфейсы, которые вообще привязаны к визуальной составляющей только в одностороннем порядке. Это позволяет вам использовать один презентер для разных активностей имеющих набор общих данных но разную визуальную составляющую
Отсутствует определенное состояние. Представим, что мы делаем запрос в сеть, и в этот момент наша активити умирает и создается новая. Данные пришли, когда View еще не привязана к Presenter…
Такое может возникнуть например в случае, когда мы открыли activity, и потом резко повернули экран, чтобы активити пересоздалось. Тогда используйте Observable и получайте уже загруженные данные.
Вот MVVM на мой взгляд как-раз и получается чрезмерно перегруженным и уж очень сильно зависит от VIEW в понимании визуальной составляющей. В своем примере вы приводите пример obsrvable, но о минусах MVVM не упоминаете ) Исходя только из приведенного примера MVVM можно вообще использовать котлиновские callback.
Возможно просто я не умею готовить MVVM ;)
1. Не очень понял, что значит «общая View»
2. Да, presenter завязан на интерфейс. Но интерфейс же завязан на View. Т.е переиспользовать вы сможете, если контракт View содержит два метода: showData(Data) и showError()
3. Это уже переход к MVVM)
Спасибо за комментарий!
2. Да, presenter завязан на интерфейс. Но интерфейс же завязан на View. Т.е переиспользовать вы сможете, если контракт View содержит два метода: showData(Data) и showError()
3. Это уже переход к MVVM)
Спасибо за комментарий!
по первому пункту — ниже уже ответили. Под общим вью подразумевается общий интерфейс View. Когда рассказываешь про MVP главное не путать interface View из ООП и View который рендерится и отображается на экране.
по второму пункту — активность (давайте будем использовать это, вместо слова интерфейс, так мы не запутаемся) имплементирует interface View, а не зависит от него. Это же не абстрактный класс, а именно интерфейс
3. Observable это паттерн в более узком смысле, чем MVVM
по второму пункту — активность (давайте будем использовать это, вместо слова интерфейс, так мы не запутаемся) имплементирует interface View, а не зависит от него. Это же не абстрактный класс, а именно интерфейс
3. Observable это паттерн в более узком смысле, чем MVVM
1. Не очень понял, что значит «общая View»
Не знаком ни с Андроидом, ни с Котлином, но видимо имелось в виду
что вместо
interface MovieView : MvpView {
fun showMovies(movies: List<Movie>)
fun showError()
}
можно писать
interface ListView<Model> : MvpView {
fun showLists(elements: List<Model>)
fun showError()
}
и вместо
MovieViewListView<Movie>И кажется, что таких интерфейсов будет не так много как вьюх. Но это не точно.
На самом деле, ни одной из перечисленных вами проблем нет.
Презентер опирается на интерфейс, а никак не на реализацию, так что вы можете использовать его для разных вариантов одного вью. А хранение состояний в презентере — одно из худших решений, которое может придти разработчику в голову.
Храните всё в виртуальной БД уровня модели, используйте потоки, обычные или реактивные, для ленивого доступа, и забудьте о проблемах MVP.
На самом деле, у MVP есть минусы, но связаны они с совсем другими аспектами.
Когда вам последний раз нужны были «разные варианты одного вью»?
Например сегодня, когда нужно разрабатывать не только под вертикальную ориентацию экрана
Нууу, в этой ситуации обычно либо оказывается, что никакой "другой реализации" вью не нужно, либо она настолько другая, что выделить общий интерфейс не представляется возможным. Не убедили.
Вот вам пример: в окне имеется карта и список объектов. В портретной ориентации карта у вас сверху, список объектов снизу. При альбомной ориентации — карта справа, список объектов слева.
Звучит всё как: «ах, ох, всё устарело и ваще фигня, на хайпе сейчас RIBs»
На MVP реализовывались и продолжают реализовываться проекты разного масштаба. Его хорошо выбирать когда не нужна сложная поддержка как в MVI/RIBs, или кому не очень нравится замешивание работы логики/маппинга/UI внутри ViewModels в MVVM.
На MVP реализовывались и продолжают реализовываться проекты разного масштаба. Его хорошо выбирать когда не нужна сложная поддержка как в MVI/RIBs, или кому не очень нравится замешивание работы логики/маппинга/UI внутри ViewModels в MVVM.
Очень хорошая статья! Можно было ещё упомянуть Time Travel в MVI.
Правильнее сказать «Не стоит использовать MVP для любых проектов, есть проекты, для которых лучше подходят другие подходы». А то посыл статьи получается похож на «никогда не используйте самосвалы, я пробовал ездить на самосвале на работу — сложно парковать».
Трэш. Это точно хабр? Сумбурное объяснение пустоты.
Все очень плохо.
По поводу минусов MVP
1.
а. Создание интерфейса View, данные подход помогает в будущем с легкостью поменять реализацию без боли.
б. Сам интерфейс также помогает читать код, посмотрев на View можно предположить что происходить на экране, если это контракт то еще лучше.
в. Если писать код по clean arch, на пакете фичи его presentation слое будет и сам экран(фрагмент или активити) и его View с Presenter, никакой сложной навигаций.
2.
Соглашусь что презентер привязан сильнее к View. Однако переиспользовать Presenter отдельного экрана не стоит. Также это относится и к ViewModel. Проблема в том что логика отображение меняется с изменением бизнес логики, то есть приходится много менять код либо в Presenter-е либо в ViewModel, из за этого обычно больших проектах они очень толстые. Стоит завести Interactor и там прописать бизнес логику и переиспользовать, но отображение должно быть разным.
3.
а. Соглашусь что ViewModel очень упрощяет разработку. Но реализация LiveData где хранятся данные, почти такая же как и ViewState.
б. У presenter-а должны быть методы которые вызываются при onPause где и должны запросы останавливаться. В onResume заново запращивать или делать какую то другую логику. Что и в подходе с ViewModel необходимо реализовывать, остановку запросов в onCleared. Также и в onPause и onResume отписываться и заново подписываться к обсерверам, соответственно.
По поводу минусов MVP
1.
а. Создание интерфейса View, данные подход помогает в будущем с легкостью поменять реализацию без боли.
б. Сам интерфейс также помогает читать код, посмотрев на View можно предположить что происходить на экране, если это контракт то еще лучше.
в. Если писать код по clean arch, на пакете фичи его presentation слое будет и сам экран(фрагмент или активити) и его View с Presenter, никакой сложной навигаций.
2.
Соглашусь что презентер привязан сильнее к View. Однако переиспользовать Presenter отдельного экрана не стоит. Также это относится и к ViewModel. Проблема в том что логика отображение меняется с изменением бизнес логики, то есть приходится много менять код либо в Presenter-е либо в ViewModel, из за этого обычно больших проектах они очень толстые. Стоит завести Interactor и там прописать бизнес логику и переиспользовать, но отображение должно быть разным.
3.
а. Соглашусь что ViewModel очень упрощяет разработку. Но реализация LiveData где хранятся данные, почти такая же как и ViewState.
б. У presenter-а должны быть методы которые вызываются при onPause где и должны запросы останавливаться. В onResume заново запращивать или делать какую то другую логику. Что и в подходе с ViewModel необходимо реализовывать, остановку запросов в onCleared. Также и в onPause и onResume отписываться и заново подписываться к обсерверам, соответственно.
Sign up to leave a comment.
Почему вам стоит выкинуть MVP из своих проектов