构建移动应用的三种架构模式：MVC、MVP和MVVM

在使用KMM（跨平台移动开发）时，架构是至关重要的。良好的架构和遵循最佳实践可以使KMM发挥事半功倍的效果，但如果不遵循，就会面临为每个平台进行特定优化以及不断解决Bug的繁重任务，最终可能不得不放弃。

因此，尽管网络上已经有大量关于MVC、MVP和MVVM的文章，我仍然希望用简单易懂的方式重复一下我的思路。

MVC、MVP和MVVM

MVC、MVP和MVVM的文章已经很多了，我想用简单明了的方式来讲解架构的重要性。

假设你想要烹饪一道美味的披萨。让我们用这个例子来解释MVC、MVP和MVVM：

MVC

你向厨师提出了请求：“请为我做一份披萨。”厨师回答：“好的，我会从冰箱中取出面团、番茄酱、奶酪和各种配料。然后将面团擀平，涂上番茄酱，撒上奶酪和配料，最后放入烤箱烘烤。披萨烤好后，我会将它切成块并端到你面前。”你可能会觉得厨师解释得太详细了，你只是想知道最终能够品尝到美味的披萨。

在MVC中，所有的事情都集中在一起处理，包括从冰箱取材料、制作披萨、烘烤和切割等。虽然这样做可以完成任务，但在修改和维护时会遇到许多麻烦。例如，如果你决定添加新的配料或改变烘烤方式，就需要修改整个过程。

MVP

你向厨师提出请求：“请为我做一份披萨。”厨师回答：“好的，我会为你准备一份美味的披萨。你只需要等待，我会在餐桌上为你准备好。”你无需关心披萨的制作过程和烤箱的使用，你只需要等待享用美味的披萨。然而，你可能突然想起忘了购买披萨的配料，而那个店恰好在你去厨师那里的反方向。

在MVP中，我们把制作披萨和使用烤箱等过程交给了厨师（Presenter）来处理，你不需要关心具体的过程，相信厨师会处理好。你只需要等待厨师根据你的请求提供披萨。

MVVM

你向厨师提出请求：“请为我做一份披萨。”厨师回答：“好的，桌子上会有一份披萨。你可以随意选择各种调料和配菜来搭配你的披萨。”

ViewModel同样是一个代理人的角色，与Presenter不同之处在于，ViewModel不关心数据如何被使用。ViewModel只负责提供数据，而数据如何展示在披萨上或者配菜如何搭配，完全由展示数据的部分决定。View和ViewModel之间的依赖关系使用观察者模式来实现。

有人可能会问：“使用了DataBinding或LiveData，是不是就是MVVM了？”实际上，这些只是辅助实现MVVM的一些工具，关键在于如何使用。例如，如果你每次使用LiveData都直接调用getValue而不是observe来接收数据变化，或者在使用DataBinding时把整个View传递给ViewModel，那就失去了MVVM设计的初衷，即降低耦合度。

KMM的架构设计正好类似于MVVM模式，内部数据不关心如何被使用，只知道有人需要数据时就提供给他。因此，无论外部发生多大变化，甚至从Android切换到iOS，对于KMM的共享层来说都是一样的。