在过去的几年里,将Android应用程序转变成逻辑组件的方法已经逐渐成熟。很大程度上摆脱了MVC模式,转而采用更模块化、可测试的模式。
Model View Presenter (MVP) & Model View ViewModel (MVVM)是最广泛被采用的两种替代方案。本文不去讨论哪种方式更适合于Android应用开发,只是通过案例来看到每种模式是如何编写的。
本文通过实现一个井字游戏,分别通过MVC、MVP、MVVM三种模式实现游戏效果。源代码已经上传到仓库中。
MVC
Model, View, Controller将应用程序在宏观层面分为3中职责。
Model
Model模型是应用程序中的数据+状态+业务逻辑。可以说是应用程序的大脑,不受View视图和Controller控制器的束缚,因此很多情况下是可以复用的。
View
View视图是Model的展现,负责呈现UI并在用户与应用程序交互时与Controller通信。在MVC架构中,视图通常很“愚蠢”,因为他们不了解底层模型,也没有对状态的理解,或者当用户通过单击按钮,键入值等进行交互时要做什么。这个想法是越少他们知道他们对模型的耦合越松散,因此他们要改变的就越灵活。
Controller
Controller是将app粘在一起的胶水,它是应用程序中的主控制器。当View告诉Controller用户单击按钮时,Controller决定如何与Model进行相应的交互。根据Model中的数据更改, Controller可以根据需要更新View的状态。在Android应用程序中,Controller几乎总是由Activity或Fragment来担任的。
这就是我们的井字游戏中每个类扮演的角色
让我们更详细地检查Controller。
|
|
评估
MVC在分离模型和视图方面做得很好。当然,该模型可以很容易地进行测试,因为它不依赖于任何东西,并且视图在单元测试级别上没有什么可测试的。然而,控制器有一些问题。
Controller关注
- 可测试性 - Controller与Android API紧密联系,难以进行单元测试。
- 模块化和灵活性 - Controller与View紧密耦合。它也可能是View的扩展。如果我们更改View,我们必须返回并更改Controller。
- 维护 - 随着时间的推移,越来越多的代码开始转移到Controller中,使它们变得臃肿和脆弱。
我们如何解决这个问题?MVP来拯救!
MVP
MVP将Controller断开,以便自然View/Activity耦合可以发生,而不会与其他“Controller”责任相关联。让我们再次从MVC对比开始。
Model
与MVC相同/无变化
View
这里唯一的变化是Activity/Fragment现在被视为View的一部分。让Activity实现一个视图界面,以便Presnenter有一个可以编码的界面。这消除了将它耦合到任何特定的页面,并允许使用视图的mock实现进行简单的单元测试。
Presenter
这实质上是MVC的Controller,除了它完全不依赖于View,只是一个接口。这解决了可测试性问题以及我们在MVC中遇到的模块化/灵活性问题。实际上,MVP纯粹主义者认为Presenter不应该对任何Android API或代码有任何引用。
我们再来看看在我们的应用程序中在MVP中的分解。
在下面更详细地看看Presenter,你会注意到的第一件事是每个动作的意图是多么简单和清晰。它不是告诉View如何显示某些东西,而只是告诉它要显示什么。
|
|
为了在不将Activity与Presenter绑定的情况下进行这项工作,我们创建了一个Activity实现的接口。在测试中,我们将基于此接口创建一个mock来测试与Presenter和View的交互。
|
|
评估
我们可以很容易地对Presenter逻辑进行单元测试,因为它没有绑定到任何Android特定的View和API,并且只要View实现*TicTacToeView*界面,我们也可以使用任何其他View。
Presenter的关注
- 维护 - 与Controller一样,Presenter随着时间的推移,倾向于收集额外的业务逻辑。在某些时候,开发者经常会发现自己拥有难以分开的笨重的Presenter。
当然,开发人员可以谨慎的防止这种情况发生。但是,MVVM可以更好的解决这个问题。
MVVM
Android上具有数据绑定功能的 MVVM具有易于测试和模块化的优点,同时还减少了我们必须编写的连接View +Model的代码数量。
我们来看看MVVM的各个部分。
Model
与MVC相同/无变化
View
该View以一种灵活的方式绑定到由viewModel来监控可观察的变量和操作。
ViewModel
ViewModel负责包装Model并准备View所需的可观察数据。它还为View提供了将事件传递给Model的hocks。然而,ViewModel并不依赖于View。
我们的程序早MVVM模式中分解。
让我们仔细看看这里的代码,从ViewModel开始。
|
|
查看xml文件,看看这些变量和事件是如何绑定的。
|
|
评估
单元测试现在更容易,因为你真的不依赖于View。测试时,您只需要验证Model更改时是否正确设置了可观察变量。没有必要mock测试View,因为有MVP模式。
MVVM关注
- 维护 - 由于View可以绑定到变量和表达式,因此无关的表示逻辑可能会随着时间的推移而变动,从而有效地将代码添加到我们的XML中。为了避免这种情况,总是直接从ViewModel获取值,而不是试图在视图绑定表达式中计算或派生它们。这样计算可以适当地进行单元测试。
结论
MVP和MVVM在将应用程序分解为模块化单一用途组件方面比MVC做得更好,但它们也增加了应用程序的复杂性。对于只有一个或两个屏幕的非常简单的应用程序,MVC可能工作得很好。带有数据绑定的MVVM具有吸引力,因为它遵循更加反应式的编程模型,并且生成的代码更少。
如果您有兴趣在实践中看到MVP和MVVM的更多示例,我鼓励您查看Google Architecture Blueprints项目。还有很多博客文章深入探讨这几种模式
参考
https://academy.realm.io/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android