【译】Android架构模式：MV(C|P|VM)

这是再Medium上看到的一篇文章，作者根据根据两年多开发经验总结出来的对MVC、MVP、MVVM架构模式的理解。有兴趣的可以点击文末链接阅读原文（需科学上网）。

MVP架构模式在Android设计中已经应用的比较广泛了，去年又在Android中引入了MVVM架构设计模式，相较于传统的MVC模式，这三种模式都有相同的两个元素：

• M: Model
• V: View

其中，Model主要负责业务逻辑，它和网络层和数据库打交道，并对外暴露接口。在Android中，该层应该被设计为完全独立的一层。
View层主要负责渲染显示数据。
如题目(C|P|VM)，分别代表：C:Controller层，P:Presenter层，VM：ViewModel获取数据的中间层。
在这三种模式中，View分别和Controller、Presenter、ViewModel打交道。接下来，分别看看这三种模式。

MVC：Model-View——Controller

如上图，在MVC中，Controller得到用户输入，然后更新Model层，Model层被更新后，Controller层再告知View层去查询Model层，得到最新数据。这是经典的MVC模式，我们再看看在Android中的MVC模式。

MVC在Android中的使用

在Android中，Activity同时扮演着View和Controller的角色。

对于一个系统架构来说，重要的一点是能分割成不同的职能层来确保可测试，如上图的这个架构显然是不符合这个要求的，尽管Model是可测试的，但是View层和Controller层不可测试。
如何去解决这个问题呢，我们需要将Controller层移除Activity。Activity层单独扮演View的功能，并且由View（即Activity）来和用户交互。

如上图，当View层接收到用户输入，需要告知Controller层，然后Controller层更新Model；更新完成后，Controller层告知View层更新界面，此时View层查询Model层得到最新数据，最终更新界面。
更改后的MVC模式依然存在一个问题，View层和Controller层相互持有对方的引用，依然难以测试；并且View层还和Model层间有交互。

MVP：Model-View-Presenter

在MVP模式中，通过Presenter替换了Controller，并且View和Presenter是一对一的关系：一个View对应于一个Presenter，同样的一个Presenter对应于一个View。View和Presenter之间通过接口联系。

View层告知Presenter层用户的行为，Presenter通过传递过来的用户行为触发Model层，比如获取最新数据，更新得到数据后，再通过Presenter层告知View层更新。其中有几点值得关注：

1. View层不会直接和Model打交道
2. Presenter层作为中间者，分别与Model层和View层通信
3. View层只接受用户的相关行为，并把用户行为交给Presenter处理

由于View和Presenter通过接口相互引用，因此MVP架构模式下的代码是很容易测试的。
让我们再从事件驱动（Event-Based）的角度重新审视一下MVP模式。Presenter可以看作是事件的生产者，而View可以被认为是事件的消费者。如果Presenter是生产者，那么它就不需要关心谁来消费这个事件；生产者产生数据流，谁关注这些数据，只要订阅即可。由此我们可以得到另外一种架构模式MVVM模式。

MVVM：Model-View-ViewMod

在MMVM模式中，我们通过ViewModel从Model获取数据，然后ViewModel可以暴露数据给关心这些数据的View层。

相比较于MVP，MVVM减少了模板代码。结合RxJava2的MVVM非常适合在Android应用程序中创建基于事件的UI。

总结

MVC vs MVP vs MVVM

MVP和MVVM提供单一职责和可测试性的分离。但MVC vs MVP vs MVVM，你应该使用哪一个？它实际上并不重要。只要问这3个问题：

1. 你的Android类逻辑是准确无误的吗？
2. 你能对所有东西进行单元测试吗？
3. 你的每一个类只做一件事吗？

如果您能回答“是”，那么对于所有这3个问题，这意味着您拥有一个健壮，稳定，可测试，模块化，易于扩展的应用程序。

译文原文：https://medium.com/mindorks/android-architecture-patterns-mv-c-p-vm-4594574eeaa1