【51CTO.com原創(chuàng)稿件】2007年第一代iPhone的發(fā)布開啟了智能手機(jī)的新時(shí)代，至今移動(dòng)開發(fā)已跨越了十年的路程，十年中有著太多的改變。隨著移動(dòng)互聯(lián)網(wǎng)的突飛猛進(jìn)，人們的生活方式也在日益變化著，身處在單調(diào)生活中的人們也開始注重健康的生活方式，咕咚（Codoon）則是看中了這一市場，致力于通過游戲化、社交化和碎片化的方式，來鼓勵(lì)人們形成良好的運(yùn)動(dòng)習(xí)慣和生活方式，從而獲得身體的健康。

此次由51CTO主辦的2017WOTA全球架構(gòu)與運(yùn)維技術(shù)峰會上，咕咚技術(shù)總監(jiān)唐平麟老師分享了主題為《第十年的選擇》的演講。

[[189728]]

咕咚作為中國最大的運(yùn)動(dòng)社交服務(wù)平臺，其APP需要與手機(jī)硬件綁定的非常多，基本使用到手機(jī)里所有芯片和感應(yīng)器，所以相對于其他APP在架構(gòu)的選擇上會更加保守一些。為了照顧與手機(jī)硬件的綁定，咕咚幾乎沒有用到React Native等動(dòng)態(tài)化的技術(shù)，為了保證系統(tǒng)的穩(wěn)定性，咕咚更偏向于選擇原生實(shí)現(xiàn)。架構(gòu)上偏保守的實(shí)現(xiàn)會相對比較復(fù)雜，而咕咚就面臨著這樣的難題。

咕咚最開始選擇的是MVC的框架。經(jīng)典的MVC與蘋果的MVC不太一樣，蘋果的MVC里的Model（數(shù)據(jù)管理者）、View（數(shù)據(jù)展示者）、Controller（數(shù)據(jù)加工者）是互相聯(lián)系的，導(dǎo)致所有對Model的操作必須經(jīng)過Controller，如此一來， Controller會越來越大。在經(jīng)典的MVC里面，View跟Controller是可以同性的，而蘋果的則不可以，Cocoa MVC = MVC + Data Service缺少了View跟Model之間的聯(lián)系，這就是為什么蘋果的架構(gòu)里面Controller會越來越大，最后會導(dǎo)致非常大的問題。

胖Model包含了部分弱業(yè)務(wù)邏輯。胖Model要達(dá)到的目的是，Controller從胖Model這里拿到數(shù)據(jù)之后，不用額外做操作或者只要做非常少的操作，就能夠?qū)?shù)據(jù)直接應(yīng)用在View上。瘦Model只負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的表達(dá)，所有業(yè)務(wù)無論強(qiáng)弱一律到Controller上。瘦Model要達(dá)到的目的是，盡一切可能去編寫細(xì)粒度Model，配套各種helper類或方法來對弱業(yè)務(wù)做抽象，強(qiáng)業(yè)務(wù)依舊交給Controller。一旦選擇了胖Model，Controller拿到數(shù)據(jù)之后，不用做太多的選擇，就可以把數(shù)據(jù)顯示在Controller里面。有時(shí)候?yàn)榱诉x擇，咕咚也會使用瘦Model，但是不敢將任何業(yè)務(wù)邏輯都不寫到Model里面，只是把Model當(dāng)做一個(gè)存儲數(shù)據(jù)的目的。這時(shí)候業(yè)務(wù)的處理還是需要Controller，這兩種設(shè)置其實(shí)本身沒有什么高低之分，但是對于咕咚來說還是胖Model更適合一些。

不論是服務(wù)端、前端還是客戶端，搜集模式是開發(fā)者們都最常用的，資料也相對完全?？墒荕VC的架構(gòu)導(dǎo)致了高耦合和復(fù)雜的代碼，為了解決這個(gè)問題再引入下一個(gè)架構(gòu)。在MVC里邊，怎么去劃分這個(gè)代碼才更加地清晰、更加地合理，唐平麟老師認(rèn)為 “要嚴(yán)格讓Model變成一個(gè)胖Model”，這樣便于View Controller不用做復(fù)雜的程序就能獲得數(shù)據(jù)。

但是有些時(shí)候在設(shè)計(jì)框架的時(shí)候，并沒有嚴(yán)格的去設(shè)計(jì)，這時(shí)就需要引入另外一種模式， MVVM。它僅僅做了一件事情，就是把View Controller拆開了，把View Controller拆成了View Model，把之前Controller對于Model的控制代碼全部放到了View Model里去。如此一來，業(yè)務(wù)邏輯就會非常地清晰、框架也會更加地明顯。View Controller僅僅是做顯示性的東西，View Model是做業(yè)務(wù)上的處理， Model可以設(shè)計(jì)成胖Model，也可以設(shè)計(jì)成瘦Model，如果設(shè)計(jì)成胖Model的話，可以把最簡單的邏輯放在Model里面去處理，如果設(shè)計(jì)成瘦Model的話，可以把全部數(shù)據(jù)都放到View Model去處理。

MVVM的View Controller不像在MVC里的View Controller，MVVM的是View Controller + View，皆統(tǒng)成一層，而這一層都是做顯示的邏輯。值得注意的是，在做視圖層和View Model層的話，這兩個(gè)之間要用一個(gè)Data綁定的技術(shù)，為了實(shí)現(xiàn)這個(gè)Data綁定，不能用第三方的庫補(bǔ)充。View Model的角色是處理業(yè)務(wù)邏輯，除了被View層持有，也會持有Model。簡而言之，View Model是一個(gè)從上到下互相持久的關(guān)系，在MVC架構(gòu)里面經(jīng)常會造成三者之間的相互持有，為了開發(fā)過程，可能讓Model、Controller與View之間會產(chǎn)生相互持有的關(guān)系。

從MVC一直到MVVM，當(dāng)程序越來越復(fù)雜的時(shí)候，開發(fā)者們必須嚴(yán)格地去定義每一個(gè)工作模塊應(yīng)該干什么，只有這個(gè)時(shí)候代碼才能更加地清晰可靠。

唐平麟老師在此建議大家，“我希望大家在以后的工作里面，在項(xiàng)目組里面還是傾向于用比較簡單的MVC的架構(gòu)，但是在項(xiàng)目啟動(dòng)的時(shí)候一定要嚴(yán)格區(qū)分好這三者之間的關(guān)系，這三者之間什么代碼能寫、什么代碼不能寫，什么代碼應(yīng)該放在什么里面，比如說我Model里面一定要用胖Model，我在Controller里面一定不能夠操作View層的動(dòng)畫，我在View里面一定不能去寫用戶跟業(yè)務(wù)代碼相關(guān)的邏輯，如果說我們做好這三點(diǎn)的話，我們在MVC里面依然是可以去做架構(gòu)的。”

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】