原文地址 ? 作者：佚名
- MVC作為老牌架構(gòu), 優(yōu)點(diǎn)在于將業(yè)務(wù)場(chǎng)景按展示數(shù)據(jù)類型劃分出多個(gè)模塊, 每個(gè)模塊中的C層負(fù)責(zé)業(yè)務(wù)邏輯和業(yè)務(wù)展示, 而M和V應(yīng)該是互相隔離的以做重用, 另外每個(gè)模塊處理得當(dāng)也可以作為重用單元. 拆分在于解耦, 順便做了減負(fù), 隔離在于重用, 提升開發(fā)效率. 缺點(diǎn)是沒有區(qū)分業(yè)務(wù)邏輯和業(yè)務(wù)展示, 對(duì)單元測(cè)試不友好.
- MVP作為MVC的進(jìn)階版, 提出區(qū)分業(yè)務(wù)邏輯和業(yè)務(wù)展示, 將所有的業(yè)務(wù)邏輯轉(zhuǎn)移到P層, V層接受P層的數(shù)據(jù)更新通知進(jìn)行頁(yè)面展示. 優(yōu)點(diǎn)在于良好的分層帶來(lái)了友好的單元測(cè)試, 缺點(diǎn)在于分層會(huì)讓代碼邏輯優(yōu)點(diǎn)繞, 同時(shí)也帶來(lái)了大量的代碼工作, 對(duì)程序員不夠友好.
- MVVM作為集大成者, 通過(guò)數(shù)據(jù)綁定做數(shù)據(jù)更新, 減少了大量的代碼工作, 同時(shí)優(yōu)化了代碼邏輯, 只是學(xué)習(xí)成本有點(diǎn)高, 對(duì)新手不夠友好.
- MVP和MVVM因?yàn)榉謱铀詴?huì)建立MVC兩倍以上的文件類, 需要良好的代碼管理方式.
- 在MVP和MVVM中, V和P或者VM之間理論上是多對(duì)多的關(guān)系, 不同的布局在相同的邏輯下只需要替換V層, 而相同的布局不同的邏輯只需要替換P或者VM層. 但實(shí)際開發(fā)中P或者VM往往因?yàn)轳詈狭薞層的展示邏輯退化成了一對(duì)一關(guān)系(比如SceneA中需要顯示”xxx+Name”, VM就將Name格式化為”xxx + Name”. 某一天SceneB也用到這個(gè)模塊, 所有的點(diǎn)擊事件和頁(yè)面展示都一樣, 只是Name展示為”yyy + Name”, 此時(shí)的VM因?yàn)轳詈蟂ceneA的展示邏輯, 就顯得比較尷尬), 針對(duì)此類情況, 通常有兩種辦法, 一種是在VM層加狀態(tài)進(jìn)而判斷輸出狀態(tài), 一種是在VM層外再加一層FormatHelper. 前者可能因?yàn)闋顟B(tài)過(guò)多顯得代碼難看, 后者雖然比較優(yōu)雅且拓展性高, 但是過(guò)多的分層在數(shù)據(jù)還原時(shí)就略顯笨拙, 大家應(yīng)該按需選擇.
這里隨便瞎扯一句, 有些文章上來(lái)就說(shuō)MVVM是為了解決C層臃腫, MVC難以測(cè)試的問(wèn)題, 其實(shí)并不是這樣的. 按照架構(gòu)演進(jìn)順序來(lái)看, C層臃腫大部分是沒有拆分好MVC模塊, 好好拆分就行了, 用不著MVVM. 而MVC難以測(cè)試也可以用MVP來(lái)解決, 只是MVP也并非完美, 在VP之間的數(shù)據(jù)交互太繁瑣, 所以才引出了MVVM. 當(dāng)MVVM這個(gè)完全體出現(xiàn)以后, 我們從結(jié)果看起源, 發(fā)現(xiàn)它做了好多事情, 其實(shí)并不是, 它的前輩們付出的努力也并不少!
架構(gòu)那么多, 日常開發(fā)中到底該如何選擇?
不管是MVC, MVP, MVVM還是MVXXX, 最終的目的在于服務(wù)于人, 我們注重架構(gòu), 注重分層都是為了開發(fā)效率, 說(shuō)到底還是為了開心. 所以, 在實(shí)際開發(fā)中不應(yīng)該拘泥于某一種架構(gòu), 根據(jù)實(shí)際項(xiàng)目出發(fā), 一般普通的MVC就能應(yīng)對(duì)大部分的開發(fā)需求, 至于MVP和MVVM, 可以嘗試, 但不要強(qiáng)制.
總之, 希望大家能做到: 設(shè)計(jì)時(shí), 心中有數(shù). 擼碼時(shí), 開心就好.
