ｉＯＳ中的ＭＶＣ和ＭＶＰ
Cocoa版本的MVC
Cocoa版本的MVC
根據(jù)官網(wǎng)的描述，Cocoa中的MVC是這樣的
- model objects Encapulate Data and Basic Behavious
- View Objects Present Informaiton to the User
- Controller Objects Tie The Model to the View
C 和P的差別
通過搜索引擎末盔，發(fā)現(xiàn)其實MVP有兩種
1.Passive View
2.Supervising Controller
網(wǎng)上絕到多數(shù)部分談?wù)揗VP的文章談?wù)摰钠鋵嵍际荘assive View偎行。這里放上一張Passive View的示意圖
簡而言之.MVP就是view驅(qū)動的,View層持有對應(yīng)Presenter的引用剂陡，View上的交互事件首先會調(diào)用Presenter提供的接口，人后Presenter調(diào)用Model提供的方法取得數(shù)據(jù)，最后presenter將取得的數(shù)據(jù)傳遞到View上展示
MVC則是由controller驅(qū)動的酸钦，controller持有的view菜秦，并相應(yīng)view上的交互事件甜害，根據(jù)交互調(diào)用不同的Model方法取得反饋數(shù)據(jù)，在將數(shù)據(jù)傳遞到view展示球昨。
就我個人而言尔店，我的理解是。MVP是用戶視角主慰，所見即View嚣州，MVC是程序員視角，：I control everyone.
理解MVC和MVP的差別困惑的地方在于共螺。,UIViewController到底是屬于C(P)層還是V層呢?下面將分別具體分析一下這兩種觀點
- 觀點一该肴，uiview controller的歸屬-->view
如果把UIViewController視為V層,即上面MVP示意圖中的Passive View,那么UIViewController將只負(fù)責(zé)View布局相關(guān)邏輯,不涉及任何與Model層的交互!!
所有的業(yè)務(wù)邏輯交互通過UIViewController持有的Presenter與Model間的調(diào)用來完成
觀點二:UIViewController的歸屬--->Controller
那如果把UIViewController視為C層,從MVC設(shè)計理念上來說,C層不會負(fù)責(zé)具體View的布局及展示邏輯,但是由于iOS中UIViewController的特殊設(shè)計,導(dǎo)致很多開發(fā)者直接就在UIViewController包含了很多具體布局相關(guān)的代碼,更可怕的情況是不止是View的初始化,包括網(wǎng)絡(luò)請求及具體業(yè)務(wù)處理也被包含到UIViewController中,這也許就是有人戲稱MVC為:MassiveViewController的原因
本次基于MVC的項目重構(gòu)步驟
思考要解決的問題
回到項目重構(gòu)的問題上來，我認(rèn)為項目重構(gòu)要想清楚的問題：
１藐不，項目層級如何劃分的匀哄。
２，大的業(yè)務(wù)場景有哪些佳吞？
３拱雏，將UIView Controller歸類為View還是Controller
４，誰來負(fù)責(zé)網(wǎng)絡(luò)請求底扳，Model還是Controller铸抑？
５，從Model中取得數(shù)據(jù)后Controller怎么把數(shù)據(jù)傳遞給View去展示衷模？按照view層級主機遞增鹊汛？是否需要使用View Model
６.Model的生命周期怎么控制蒲赂？（全局和私有Model的劃分）
7，View層級結(jié)構(gòu)越來越深時刁憋，怎么傳遞用戶的交互操作滥嘴？（毫無疑問是NSNotification）
UIview Controller的劃分
本次重構(gòu)中還是UIview Controller歸類為C層，但是為了將UIview Controller徹底和UIview分離開至耻。命名上我們直接使用XXXController若皱。我們對每一個XXXController設(shè)計了一個對應(yīng)的名為的XXXContatinerView的UIView對象。所有的view布局都會在這個XXXControllerView中完成尘颓。
業(yè)務(wù)場景劃分
由于之前趕進度開發(fā),沒有做具體的功能拆分.本次重構(gòu)之前使用了StartUML繪制了主要場景下的UML圖,包括類圖,時序圖,流程圖
強烈推薦新項目正式編碼之前就完成這一步,并由前后端技術(shù)負(fù)責(zé)人主持進行UML評審.所有涉及到的業(yè)務(wù)Model的property以及public方法,所有DataInfo類的屬性,甚至所有的Controller都會在繪制UML的過程中產(chǎn)出.當(dāng)然,要想繪制所有場景下的UML圖可能耗時比較久,一般來說只要繪制出主要交互場景即可.
