android 中 MVP 相对于 MVVM 设计模式的缺点

Drawback of MVP over MVVM design pattern in android

您好,我正在阅读这篇 post https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/,他们在其中对 mvc、mvp、mvvm 进行了很好的解释。我了解了 mvp 设计模式的工作原理。

我没有发现 MVP 比 MVVM 有任何缺点。正如他们所说,这是个问题

Presenter Concerns -> Maintenance - Presenters, just like Controllers, are prone to collecting additional business logic, sprinkled in, over time. At some point, developers often find themselves with large unwieldy presenters that are difficult to break apart.

任何人都可以通过示例解释它的含义以及如何使用 MVVM 解决它吗?

我是 MVP 的忠实拥护者,并没有真正尝试过 MVVM。 Presenter 可能失控的缺点是我经历过的事情,但可以减轻。

在 post 的示例中,业务逻辑将相对简单。可能只有一个模型需要处理,没有太多复杂的逻辑。

让我们考虑一个更复杂的例子。假设您有一个卖花的应用程序。一旦用户选择了他们的花束,他们就会被带到订单选项屏幕,在那里他们可以:

  • 给鲜花留言
  • 选择一个礼物花瓶
  • select post年龄地址
  • 选择交货日期

然后添加一些域要求:

  • 如果他们在国外发货,您将无法添加消息
  • 部分地区交货时间不同
  • 有些花瓶只能搭配一些花

这可能不是最好的用户体验,但抛开它你现在有一个 Presenter 必须处理许多不同的 Model(帐户、地址、花瓶、订单)并且可以非常迅速开始承担许多责任,而不仅仅是告诉 View 要显示什么并将事件传递给 Model。这违反了单一职责原则。另外,每当 class 开始超过 500 行时,我就会开始心烦意乱。

虽然解决方案相对简单。您将所有单独的逻辑位分离到 UseCase classes 中。我使用比较简单的基础class如下:

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);
}

您指定一个输入和输出类型,并在具体实现的构造函数中注入您需要的所有模型class。 Presenter 获取事件并将来自 View 的输入传递给适当的 UseCase,然后使用 Model 和 returns 适当的数据执行复杂的逻辑给 Presenter 以更新 View.

如果需要更新 UI 状态,您可以使用状态将定期状态更新发送回您的 Presenter

这样您的 Presenter returns 就可以成为 ViewModel 之间传输数据和事件的简单管道,并且业务逻辑很好地包含在每个动作一个单独的 class。

正如文章中MVVP介绍中所说:

MVVM with Data Binding on Android has the benefits of easier testing and modularity, while also reducing the amount of glue code that we have to write to connect the view + model.

MVP 和 MVVP 的主要区别是:

  • View层:在MVP中,你的View完全是一个哑巴被动的View。但是在 MVVP 中,你的 View 更灵活,因为它可以绑定到 observable。
  • 在MVP中,你的Presenter因为dumb View几乎包揽了一切,所以它会逐渐变得非常大和复杂。同时,在MVVP中,ViewModel有View的支持(有点聪明:D),尤其是Data Binding,可以减少一部分逻辑代码。
  • 因此,你会为Presenter写很多代码,而且逻辑上相互关联,很难分解。

但是,许多开发人员更喜欢 MVP,因为他们不希望某些业务逻辑代码成为 XML 布局的一部分。