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