Day 2:根基不牢，怎麽建高楼．来聊聊架构．

Keyword: MVC，MVP，MVVM

在使用KMM上，架构是重中之重．如果使用了好的架构并且遵循，KMM就能帮助你达成事半功倍的效果，但是如果没有好好遵守，不仅要为了每个平台进行特化，还会为了层出不穷的Bug疲於奔命，最後黯然放弃．

因此，虽然网路上关於MVC,MVP,MVVM的文章已经超级多了，我仍然会重复一次我的思路．我会试图把架构讲得比较轻松，容易了解．

MVC,MVP,MVVM

用一个生活上的例子来代表 :

假设你约好要到朋友家去玩，希望到车站时可以接你....

MVC

朋友回答: 好的，我会开一台1996年由福特生产，内部有配备Ａ牌安全气囊> > ......由台湾公司代理的白色小汽车，车牌是ACC-1425，我会汉口路右转，再走民权西路.....最後在车站接你回来．如果朋友这样回答，你一定是觉得说这麽多干嘛？车子是怎麽生产，走什麽路来的，对於你来说，根本不是重点．

最常见的写法，将所有事情都一鼓脑儿塞进同个地方之中，如何取资料，取完资料要做什麽什麽处理，怎麽传递，如何呈现在画面上，通通在一个地方做完．

虽然有达到了功能面，但是在修改及维护上会有许多的麻烦，例如有天政府下令所有的汽车都要更新自动导航，就要一台一台车去检查．随着政府的要求越来越多，车子也变得越来越混乱．在测试时更是会测到吐出来，最後只能靠人去一个一个尝试．

MVP

朋友回答:好的，我会开车去接你回来．不用知道车子的生产过程，也不用知道中间的路程．这些过程都交给朋友帮你处理好了．你所需要做的就是等朋友来然後舒舒服服的坐车去朋友家...等等，突然想到还没买给女朋友的名产...那家店刚好跟你朋友家是反方向

我们将生产与传递资料的事物交给一个代理人(Presenter)全权处理，并不需要知道资料的来源．相信代理人会处理好这个部分的事物．View所需要做的就是等Presenter根据你的行为提供资料．

但是基本上就是跟这个Presenter绑定了，View需要知道Presenter，而Presenter也需要知道View．在画面逻辑新增或修改的时候，需要同时改写View和Presenter两方，大幅增加工作量

MVVM

朋友回答:好的，会有台车在那．到了车站有台车就停在你面前，你想要做什麽都可以....

ViewModel同样是一个代理人的身份，与Presenter不同的地方在於，ViewModel不在意资料是

如何被使用的．ViewModel只负责提供资料，要拿去显示在RecyclerView上也好，或是跳出Dialog也罢，那都是使用资料的View层所决定的．而View与ViewModel可以做的单方面的依赖就是利用到了观察者模式的特性．

常常有人问，"使用了DataBinding或是LiveData，是不是就是MVVM了?"，其实这些都是Google官方辅助的一种MVVM实作，还是要看怎麽使用，我曾看过新人每次使用到LiveData时全部使用getValue

而不是observe来接收数值变化．或是使用DataBinding时把整个View传进ViewModel里面，这些都失去了MVVM初始为了降低耦合程度的设计

而KMM的架构设计就有如最後一个MVVM的模式，内层的资料不了解被谁使用了，只知道有人要资料我就给他，也因此外层有再大的变化，甚至从Android换成iOS了，对於KMM的共用层都是一样的．