MVC
MVC的優缺點
優點
MVC的低耦合性、高重用性、可維護性等優點顯而易見，使得原本復雜的代碼與界面的交互變得簡單、清晰、明了，開發者可以把更多的精力放在前端界面的設計上，而不用絞盡腦汁去思考究竟應該如何使界面得到同步，這樣減輕了設計壓力，也從另一方面使用戶得到更多更好的享受體驗
缺點
1.愈發笨重的Controller
2.太過於輕量級的Model
3.較差的可測試性
- (MVC的另一個大問題是,它不鼓勵開發人員編寫單元測試。由於控制器混合了視圖處理邏輯和業 務邏輯,分離這些成分的單元測試成了一個艱巨的任務。大多數人選擇忽略這個任務,那就是不做 任何測試。
上文提到了控制器可以管理視圖的層次結構;控制器有一個“view”屬性,並且可以通過IBOutlet訪 問視圖的任何子視圖。當有很多outlet時這樣做不易於擴展,在某種意義上,最好不要使用子視圖 控制器(child view controller)來幫助管理子視圖。
在這里有多個模糊的標准,似乎沒有人能完全達成一致。貌似無論如何,view和對應的controller 都緊緊的耦合在一起,總之,還是會把它們當成一個組件來對待。Apple提供的這個組件一度以來 在某種程度誤導了大多初學者,初學者將所有的視圖全部拖到xib中,連接大量的IBoutLet輸出口屬 性,都是一些列問題。
)
4.遺失的網絡邏輯
- (蘋果使用的MVC的定義是這么說的:所有的對象都可以被歸類為一個Model,一個view,或是一個 控制器。就這些。那么把網絡代碼放哪里?和一個API通信的代碼應該放在哪兒? 你可能試着把它放在Model對象里,但是也會很棘手,因為網絡調用應該使用異步,這樣如果一個網 絡請求比持有它的Model生命周期更長,事情將變的復雜。顯然也不應該把網絡代碼放在view里, 因此只剩下控制器了。這同樣是個壞主意,因為這加劇了厚重控制器的問題。)
5.定義模糊的“Manage”
______之前我提到了view controller可以管理試圖的層次結構；view controller有一個“view”屬性，並且可以通過IBOutlet訪問視圖的任何子視圖。當有很多outlet時這樣做不易於擴展，在某種意義上，最好不要使用子視圖控制器（child view controller）來幫助管理子視圖（subview）。要點在哪？驗證用戶輸入的業務邏輯應歸入controller還是model呢？在這里有多個模糊的標准，似乎沒有人能完全達成一致。貌似無論如何，view和對應的controller都緊緊的耦合在一起，總之，還是會把它們當成一個組件來對待。
MVVM
在經歷了一大堆吐槽之后,誕生了MVVM(一個高大尚牛逼哄哄的名詞,從此又多了一種人,你懂MVVM ？如果你的回答是否,瞬間被鄙視一把)。
Model-View-ViewModel
-
1.在MVVM里，view和view controller正式聯系在一起，我們把它們視為一個組件。視圖view仍然不能直接引用模型model，當然controller也不能。相反，他們引用視圖模型view model。
-
2.view model是一個放置用戶輸入驗證邏輯，視圖顯示邏輯，發起網絡請求和其他各種各樣的代碼的極好的地方。有一件事情不應歸入view model，那就是任何視圖本身的引用。view model的概念同時適用於於iOS和OS X。（換句話說，不要在view model中使用 #import UIKit.h）
優點
- 1.由於展示邏輯（presentation logic）放在了view model中，視圖控制器本身就會不再臃腫。當你開始使用MVVM的最好方式是，可以先將一小部分邏輯放入視圖模型，然后當你逐漸習慣於使用這個范式的時候再遷移更多的邏輯到視圖模型中。
- 2.使用MVVM的iOS app是高度可測試的；因為view model包含了所有的展示邏輯並且不會引用view，所以它可以通過編程方式充分測試
- 3.使用MVVM會輕微的增加代碼量，但總體上減少了代碼的復雜性。這是一個划算的交易。
為什么要mvp
- MVC、MVVM,真實的業務場景中,如果場景的邏輯異常復雜,在反復的迭代中仍會出現 各式各樣的問題。真對MVVM我個人理解主要是將原來Controller中處理數據邏輯的代碼統一歸 到一個新的class(viewModel)中去,更甚之網絡請求等工作全部從Controller移到viewModel。 剛一開始總覺的怪怪的。
- MVVM層將對應的 一部分邏輯處理移植到了ViewModel中,這並沒有從根本上解決問題,無非是將代碼做了一份對應 的copy轉移,並沒有從根本上達到邏輯分層的概念。相反MVP模 式恰好解決了這一難題,MVP模式衍生於傳統service架構,針對不同的業務場景圖供對應的匹配的 抽象service服務,客戶端拿到網絡數據后未達到指定的目的,為滿足相同抽象邏輯的業務場景,在客戶端網絡層與Model層之間加一協議層,Model層實現整個 協議層,之后在基於MVC的結構下將一概相同層次的,業務場景繪制解釋到對應的View上。
MVP
傳統web架構
(DTO是一個普通的Java類，它封裝了要傳送的批量的數據。當客戶端需要讀取服務器端的數 據的時候，服務器端將數據封裝在DTO中，這樣客戶端就可以在一個網絡調用中獲得它需要的所有數據。)
現有模式:
mvp模式
- M : 邏輯Model層
- V : 視圖層
- P : protocol協議層
- Model層類似於MVVM的ViewModel,主要負責存儲抽象邏輯數據,另外Model層主還有部分工作 實現對應的協議層協議,提供協議對應的各種屬性以及服務。Model經過協議層抽象約束,最后 Model被抽象成具有統一抽象邏輯的業務場景,最終Model層在講數據交付整個MVC結構繪制展 示的時間,我們可以按照同一套抽象的邏輯標准去執行。