MVC,MVVM,MVP 優缺點

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結構繪製展 示的時間,咱們能夠按照同一套抽象的邏輯標準去執行。

___MVP模式的原則是:在service層提供一大堆不盡相同的業務場景以後,咱們將這一系列數據全 部抽象概括,經過定製一套標準的protocol協議,讓不一樣業務場景的都去實現這一協議,最終將 數據所有裝配、拼裝成一套具備相同調度規則的統一編制話數據Model,以後咱們採用 id 的標準去操做數據。

___MVP除了將數據邏輯徹底鎮封的各自的Model,同時將哪些Model須要繪製,哪些Model須要校 驗, 哪些Model須要接受處理點擊Action這些邏輯所有由Model本身來決定,Controller只做爲 一個粘合性的模版,Controller只處理一批具備共性的範型類數據,至於具體的操做操做絕不關 心。

*___MVP面相的更多的是在MVC上層與service之間追加了一層協議層,咱們認爲經過協議層處理過的數據是暫時能夠客戶端場景使用的數據,在數據到達MVC咱們針對數據進行再加工、再構造處理,這一切所有在容器內操做。這一點徹底與別的設計模式相反。

*___MVP並非讓用戶在Model打上網絡請求操做、在Model層執行[self.navigationController pushViewController:*]等這些操做,其實相對大多人來講對於部分對象生命週期長短問題仍是 很在意,因此在處理TemplateActionProtocol協議的時間,MVP只是對準Action作了一層抽象 封裝。經過實現TemplateActionProtocol的Model會產生一個Action對象,最終經過block的調 用鏈傳回控制器中,咱們在控制器中統一作handler處理。

*___MVP咱們最初設計目的就是爲了強調一個裝配概念,若是發生了業務場景的追加,控制器我不會 改動其中的代碼,只須要將新數據追加成相同批次的ViewModel,而後配置進容器,以後控制器 不作任何修改就能夠知足需求了。經過具體的剝離、抽取咱們成功了的最大限度的剝離了控制 器,知足了輕量級Controller這一律念。

*___MVP與傳統軟件相比,在設計這一點的時間咱們徹底借鑑了傳統軟件的思惟模式,Java平臺的 service設計模式、三層架構這些設計規範都相對作了一些對比分析,最終得出了MVP這一理 念。

參考網址(http://www.jianshu.com/p/f7ff18ac1c31)