Недостаток MVP над шаблоном дизайна MVVM в android

Привет, я читаю этот пост https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/ где они очень хорошо объяснили о mvc, mvp, mvvm. Я понял, как работает шаблон дизайна mvp.

Я не нахожу никаких недостатков в MVP над MVVM. Как они предположили, это проблема

Presenter Concerns - > Maintenance-ведущие, как и контроллеры, склонны собирать дополнительную бизнес-логику, посыпанную со временем. В какой-то дело в том, что разработчики часто оказываются с большими громоздкими докладчиками, которые трудно разбить.

может ли кто-нибудь объяснить, что это значит с примером и как его можно решить с помощью MVVM ?

6
android model-view-controller mvp mvvm

2 ответов

я большой сторонник MVP и на самом деле не пробовал MVVM. Недостаток возможности a Presenter выход из-под контроля-это то, с чем у меня был опыт, но его можно смягчить.

в Примере с post бизнес-логика будет относительно простой. Вероятно, есть только одна модель, с которой нужно иметь дело, и не слишком сложная логика.

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

  • добавить сообщение к цветам
  • выберите вазу подарка
  • выберите почтовые адреса
  • выберите дату доставки

затем добавьте некоторые требования к домену:

  • вы не можете добавить сообщение, если они доставляют за границей
  • в некоторых местах имеют разные сроки доставка
  • некоторые вазы доступны только с некоторыми цветами

это может быть не лучший UX, но отложив это в сторону, у вас теперь есть Presenter это имеет дело со многими различными Models (учетная запись, адрес, вазы, заказы) и может очень быстро начать принимать на себя многие обязанности, помимо просто сказать View что отображать и передавать события в Model. Это нарушает Принцип Единой Ответственности. Также в любое время класс начинает выходить за пределы 500 строк, я начинаю расстраиваться.

решение относительно простое. Вы разделяете все ваши отдельные биты логики на UseCase классы. Я использую относительно простой базовый класс следующим образом:

public abstract class UseCase<I, O> {

    public static final int NO_STATUS = -1;

    public Observable<Integer> getStatus() {
        return Observable.just(NO_STATUS);
    }

    public abstract Observable<O> getAction(I input);
}

вы указываете тип ввода и вывода и вводите все необходимые модели в конструктор в конкретном классе реализации. The Presenter принимает события и вклада View передает это в соответствующий UseCase, это затем делает сложную логику с Model и возвращает соответствующие данные ведущему для обновления View.

вы можете отправлять периодические обновления статуса обратно на ваш Presenter используя статус, если необходимо обновить состояние пользовательского интерфейса.

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

5

Как во введении MVVP в статье сказано:

MVVM с привязкой данных на Android имеет преимущества более легкого тестирования и модульность, пока также уменьшающ количество кода клея который мы нужно написать, чтобы подключить вид + модель.

основные отличия MVP и MVVP:

  • View layer: в MVP ваш вид полностью тупой и пассивный вид. Но в MVVP ваш взгляд более гибкий, потому что он может привязываться к заметный.
  • в MVP ваш ведущий заботится почти обо всем из-за тупого взгляда, поэтому он станет действительно большим и сложным постепенно. Между тем, в MVVP ViewModel имеет поддержку из вида (его немного умный :D), особенно привязка данных, вы можете уменьшить часть логических кодов.
  • таким образом, вы напишете много кодов для Presenter, и они логически связаны, в которых вам будет трудно сломать.
, многие разработчики предпочитают MVP, потому что они не хотят, чтобы некоторые коды бизнес-логики были частью XML-макета.
2