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

Question

嗨，我正在阅读这篇文章 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 解决它吗？

Answer 1

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

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

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

• 给花留言
• 选择一个礼物花瓶
• 选择邮寄地址
• 选择交货日期

然后添加一些域要求:

• 如果他们在国外发货，您不能添加消息
• 有些地区的交货时间不同
• 一些花瓶只适用于一些花

这可能不是最好的 UX，但抛开它你现在有一个 Presenter 必须处理许多不同的 Model(帐户、地址、花瓶、订单) 并且可以很快开始承担许多责任，而不仅仅是告诉 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);
}

您指定一个输入和输出类型，并在具体实现类的构造函数中注入(inject)您需要的所有模型。 Presenter 从 View 获取事件和输入，将其传递给适当的 UseCase，然后用 Model< 执行复杂的逻辑 并将适当的数据返回给 Presenter 以更新 View。

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

这样，您的 Presenter 将返回到一个简单的管道，用于在 View 和 Model 之间传输数据和事件，并且业务逻辑是很好地包含在每个操作的单独类中。