为什么选择MVVM而不是MVP - Android体系结构

标签（空格分隔）：翻译计划 Android开发

原文链接

Why to choose MVVM over MVP — Android Architecture

Architecture????

根据维基百科的说法,Software Architecture 指的是软件系统的高层次结构,创建这样的结构的学科以及dah dah和blah blah ……我们都知道那就是架构！

简而言之,决定并实现特定的代码体系结构或设计模式都是为了解决开发人员不时遇到的问题。

Problem(问题)

一些常见问题,如代码的紧密耦合,即使代码的一部分发生小的变化,也会导致代码的其他部分发生更改/错误.
降低可重用性最终导致复制粘贴代码行。
不太适合测试等等。

Solution(解决方案)

Android本身是MVC模式写的,其中Activity负责一切事物。
对于简单的应用程序足够可以使用,但随着程序复杂性的增加,问题的数量和水平也会上升。

现在有许多不同的架构模式,像MVP,FLUX,MVI,MVVM等,这些方法在解决上述问题方面已被证明是卓有成效的。
只要代码可维护,我们就可以使用任何方法,我们也能够快速适应变化,代码一切运行良好,开发人员也会生活愉快。

End Goal(最终目标)

最终目标是以这样一种分布式架构创建事物,从而将Android相关的东西保存在一个地方,并将所有其他不需要android的实体分开运行,然后进一步拆分成依赖Android的部分,从而实现代码模块化,可扩展性、易于维护、易于测试等等…

The Question ~ Why MVVM..??(为什么是MVVM)

对于Android架构模式的无数次会议和相关文章,我们可以认为,上面讨论过的最受欢迎和被广泛采用项目架构的是MVP(即Model - View - Presenter)
同时也有很多关于此(MVP)的炒作,对此我很是感激。
它是一种成熟的模式，并且在一定程度上它实际上解决了这个问题，但是〜总是存在但不完全。

We can agree that nothing is perfect and there is always a scope for betterment.
我们可以认为任何事情都不是完美的,而是具有完善的空间

MVP是成熟的,但令人吃惊的是,Google引入了包含ViewModel而非Presenter的Android Architecture Components，因此也证明了即使Google也是支持MVVM这个项目架构的.

There must be something not right with MVP!!(MVP肯定有他的缺点)

一个简单的(不含杂质)的MVP模式如下所示:

一个简单的MVVM模式如下所示:

上面显示的是两者的简化版表示.您看得出来差别吗？？

让我们从MVP会面临的一些问题开始,以及如何利用MVVM来克服它们(问题).

Tight Coupling(紧耦合)

对于每个Activity / Fragment(View),我们都需要一个Presenter.这是一个艰难的约束规则.Presenter对Activity和Activity对于的Presenter的引用。1:1的比例关系,这个就是最大的问题所在>(相互引用).

随着程序逻辑的复杂性增加,这种关系的维护和处理难度也会增加。

这最终导致了我们之前面临的就类似于设计中的快速变化,实际上我们需要修改整个关系(解决这个暴露的问题)。

从我们的最终目标”以分布式方式创建事物”中规定一个声明,为了实现它并避免之前的(1:1)种紧密关系而引入了ViewModels。

ViewModels是简单的类,与逻辑/模型层交互,只是暴露状态/数据,实际上她并不知道谁使用这些数据、如何使用这些数据。
只有View(Activity / Fragment)持有对ViewModel的引用,反之亦然,这解决了我们的紧耦合问题。
单个视图可以保存对多个ViewModel的引用。

即使对于复杂的视图，我们也可以在同一个层次结构中使用不同的ViewModel。

Testability(方便测试)

由于Presenters很难绑定到Views,所以编写单元测试变得有些困难,因为View和Presenters有依赖关系。
ViewModels则可以很友好的进行单元测试,因为它只是暴露状态,因此可以独立测试,而不需要知道测试数据如何变化(被消费),简而言之,View没有依赖性。
这是为什么我们要选择MVVM而非MVP模式的两个重要原因。
可能有更多原因促使我们选用MVVM模式。
下面的评论正在等待它！��

Final Verdict(最终裁决)

这些体系结构模式不断发展,MVVM模式具备所有的能力,或者我们可以说其潜力巨大,实用也很高。
MVP已经发展到了一定的水平,但没有什么是完美的。

我也认可对于MVVM有一点点的学习曲线,但最终它帮助我们克服了一些缺点/问题(令我们头疼的一些问题)

不确定未来,但截至目前为止.”One fit For all solution ~ Silver Bullet”是不存在,单个模式可能不足以满足我们的产品需求。

有人可能会不喜欢MVVM,而这纯粹是由他们决定的。只要我们能够实现最终目标,别的都无所谓

PS:如果有兴趣,我还准备了一个使用Kotlin,Android Architectural Components,RxJava,Dagger实现MVVM的示例项目(样板代码设置,下面的链接).如提供反馈会建议将非常感谢.

ankitsharma6466/AndroidKotlinBoilerplate

A sample boilerplate code for building android applications based on MVVM using Kotlin, Dagger 2, RxJava, Android Architecture Components.
github.com

那么这就是这篇文章。
如果你喜欢这个,并认为我在这里做得很好,那么请不要忘记拍拍手。
你的欣赏是有价值的,同时也是我前进的动力。