如何将我们的安卓应用程序组织成相应的逻辑部件这个问题已经被讨论了很长时间了。目前大部分开发人员都抛弃了传统的Model View Controller(MVC)架构，而更青睐于更加模块化，更易于测试的新的架构。
目前Model View Presenter (MVP) 以及Model View ViewModel (MVVM)这两种新的架构成为了被广泛接受的替代方法。关于这两个架构孰优孰劣的辩论从未停止过，然而试图证明一种架构远优于另一种架构的观点大多都是基于主观的判断。这篇文章希望尽可能地撇开主观情感，来理性地分析这三种架构的价值和潜力，然后为您在开发时选择合适的架构时提供建议。
MVC
Model View Controller 架构在宏观上将应用的分为三种逻辑部件，每一种包含相应的职责。
Model
Model对于一个应用来说，通常包含了数据，状态和逻辑，是我们的应用中的核心部件。它不会与View和Controller绑定，正因为这样，通常模型的组件可以在不同的上下文中被复用。
View
View是对Model的展示，该部件的职责是渲染用户图形界面并在用户与界面产生互动时与Controller进行交互。通常，在MVC架构中View部件不了解底层的Model部件，不清楚当前的装态是什么也不知道当用户进行操作时逻辑上究竟会发生什么变化。但这正是MVC架构的优势，View与业务逻辑的耦合越低就越灵活。
Controller
Controller是整个应用的粘合剂，当View通知Controller用户做出了一些操作时，由Controller负责决定如何与相应的Model交互。同时，当Model的数据发生改变时，Controller负责根据这些数据的变化来决定更新相应的View的状态。在安卓应用中Controller通常Activity和Fragment实现。
评价
MVC架构很好地分离了model和view，但是controller存在以下问题：
可测试性：controller与安卓API绑定而难以进行单元测试
模块化和灵活性：controller与view的高度耦合导致view修改时我们往往需要修改controller
可维护性：随着应用规模变大，越来越多的代码开始转移到控制器中，使得它们变得笨重和脆弱。
如何解决这些问题呢？MVP提供了方案。
MVP
Model
与MVC一样
View
View唯一的变化在于，现在的Activity/Fragment被视为view的一部分。我们不再试图对抗他们紧密耦合的自然趋势。一种好的做法是让Activity实现view接口，这样Presenter就会可以针对接口编程。这消除了将其耦合到任何特定view，并允许对view的mock实现进行简单的单元测试。
Presenter
Presenter实际上是来自MVC的控制器，只不过它不再与View耦合，只是一个接口。这解决了MVC的可测试性问题以及模块化/灵活性问题。实际上，MVP纯粹主义者会争辩说，Presenter绝不应该包含任何对Android API或代码的引用。
评价
这种架构更加简洁。只要视图实现了相应的接口，我们可以轻松地对Presenter逻辑进行单元测试，因为它不受任何Android特定视图和API的限制，也允许我们使用任何其他的视图。
问题
可维护性：Presenter，就像Controller一样，随着时间的推移，它们倾向于增加额外的业务逻辑。在某些时候，开发人员经常会遇到难以分解的大型笨重的Presenter。
MVVM
Android的数据绑定使得MVVM架构具有更易于测试和模块化的优点，同时还减少了我们必须编写的连接视图+模型的代码。
Model
与MVC一样
View
View以灵活的方式绑定到由viewModel暴露的可观察的变量和操作。
ViewModel
ViewModel负责包装模型并准备视图所需的可观察数据。它还为视图提供了将事件传递给模型的钩子。然而，ViewModel并不与视图绑定。
评估
单元测试变得更加容易，当测试时，只需要验证在模型更改时可观察的变量是否被正确地设置。没有必要像采用MVP架构时那样mock测试的视图。
问题
可维护性：由于视图可以绑定到变量和表达式，无关的展示逻辑会随着时间的推移而蔓延，将大量添加XML中的代码。为了避免这种情况，应当直接从ViewModel获取值，而不要从视图绑定表达式中计算或推演它们。
总结
MVP和MVVM都比MVC更好地将应用程序分解为模块化的单用途组件，但它们也增加了您的应用的复杂性。具有数据绑定的MVVM具有很强的吸引力，因为它遵循更具相应性的编程模型并产生较少的代码。
