Android中MVM设计模式的缺点

Question

嗨,我正在阅读这篇文章https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/,他们很好地解释了mvc,mvp,mvvm.我知道mvp设计模式是如何工作的.

我没有发现MVP优于MVVM的任何缺点.他们认为这是个问题

演示者关注 - >维护 - 与控制器一样,演示者随着时间的推移倾向于收集额外的业务逻辑.在某些时候,开发人员经常会发现自己的大型笨重的演示者难以分开.

任何人都可以通过一个例子解释它意味着什么以及如何使用MVVM解决它？

Answer 1

我是MVP的大力倡导者并没有真正尝试过MVVM.Presenter失控的可能性的缺点是我有过的经历,但它可以减轻.

在帖子的示例中,业务逻辑将相对简单.可能只有一种模型可以处理,而不是太复杂的逻辑.

让我们想一个更复杂的例子.假设你有一个卖花的应用程序.一旦用户选择了他们的花束,他们就会进入订单选项屏幕,他们可以:

• 在花上添加一条消息
• 选择一个礼品花瓶
• 选择邮资地址
• 选择交货日期

然后添加一些域要求:

• 如果他们在国外发货,你就无法添加消息
• 某些地区的交货时间不同
• 有些花瓶只有一些花

这可能不是最好的用户体验,但放在一边你现在有一个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);
}

您可以指定输入和输出类型,并在具体实现类的构造函数中注入所需的所有模型.在Presenter从取事件和输入View通行证为适当的UseCase,这然后做复杂的逻辑与Model,并返回适当的数据给演示来更新View.

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

这样,你的Presenter回报是对之间传输数据和事件的简单管道View和Model与业务逻辑被很好地包含在每一个动作一个单独的类.

Answer 2

正如在MVVP介绍文章中所说：

Android 上带有数据绑定的 MVVM 具有更容易测试和模块化的优点，同时还减少了我们必须编写的连接视图 + 模型的粘合代码量。

MVP 和 MVVP 的主要区别是：

• View层：在MVP中，你的View完全是一个愚蠢的、被动的View。但在 MVVP 中，您的 View 更加灵活，因为它可以绑定到 observable。
• 在 MVP 中，由于愚蠢的 View，你的 Presenter 几乎负责所有事情，所以它会逐渐变得非常大和复杂。同时，在MVVP中，ViewModel得到了View的支持（有点聪明:D），特别是Data Binding，可以减少一部分逻辑代码。
• 因此，你会为Presenter写很多代码，而且它们之间逻辑上是相关的，你会发现很难分解。

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