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的共用層都是一樣的．