MVVM(微軟的WPF基礎)-MVC(經常使用模型/設計)-WPF(微軟.NETFramework3.0

最近看 好多人說IOS MVC 過期了 要用MVVM 什麼什麼的，感受 很新奇，就去搜了一下，發現原來所謂的MVVM就是 以前微軟在10年左右就推出的WPF ，鄙人不才，搞過兩年多的C#開發，所以 作了下比較：

首先來看一下 WPF

WPF（Windows Presentation Foundation）是微軟推出的基於Windows Vista的用戶界面框架，屬於.NET Framework 3.0的一部分。它提供了統一的編程模型、語言和框架，真正作到了分離界面設計人員與開發人員的工做；同時它提供了全新的多媒體交互用戶圖形界面。

那麼 模式MVVM就是：

再來看下經典的MVC：

其實這就是 把VIEW層 再次分一下 分紅view和view controller層 這讓我想起了 以前的三層架構和MVC

三層架構是最基本的項目分層結果，而MVC則是三層架構的一個變體，MVC是一種好的開發模式。首先你要明白MVC分別表明的是什麼意思.
M 即Model(模型層)，主要負責出來業務邏輯以及數據庫的交互
V 即View(視圖層)，主要用於顯示數據和提交數據
C 即Controller(控制器)，主要是用做捕獲請求並控制請求轉發

三層:UI 界面層 BLL 業務邏輯層，DAL數據訪問層，Model 實體層
MVC中的的M 不是三層中的Model(實體層)，他其實包括三層中的 BLL，DAL,Model,這是很是要注意的，這也是他們之間的區別的關鍵所在

其有點有以下：
低耦合性
高重用性和可適用性
較低的生命週期成本
快速的部署
可維護性
有利於軟件工程化管理

固然優勢也有缺點，那就是內部結構複雜，不容易理解，文件數量大，管理難度天然也就大

其實 原本是沒有區別的 或者說 是相互關聯的 具體就是

能夠看出，三層架構就是把不一樣的層次打亂 而後拆分出新的層次，這就是區別，額，感受 如今的模式都是這樣 ，可能對易老程序員來講，原來的用的順手了，可是 對於初學者，這些感念簡直就是噩夢，MVC是一種萬金油同樣的存在，你說他是設計模式也好，框架也好，總之我認爲 好用就行，全部的這些拆分或者從新組裝都是爲了更好地分離視圖和邏輯代碼以及數據庫交互，只要你的邏輯清晰，分清楚之間的關係，我以爲很容易理解，固然這也有牽扯到內聚耦合什麼的，但這不是咱們討論的重點。

關於三層架構有一個很經典的例子用於區分各個層次之間的關係，很好理解，和諸位分享一下：

一個客戶 也就是用戶  走進了一家餐館 點餐  叫服務員點菜 而後服務員去把單子給廚師  炒完菜 服務員將菜端給你 這兒過程當中產生數據  也就是製造菜的是廚師  相似於數據層 他只負責炒菜  他不知道客戶是誰  只經過服務員 來告訴他
服務員溝通客戶和廚師 業務邏輯層  客戶可能有多個需求  廚師也可能同時炒多個菜  由業務邏輯層也就是服務員負責調度 安排   裝菜的盤子  也就是 顯示層  他決定了 如何呈現菜  是大盤 仍是小盤 不一樣樣式 服務員點菜的單子  使咱們所說的實體層  它相似於一個模子 一個傳輸數據 需求 的模板

MVC缺點有哪些呢？咱們來看看那些大神的吐槽的MVC四大「缺點」：

一、厚重的View Controller

因爲大量的代碼被放進view controller，致使他們變的至關臃腫。在iOS中有的view controller裏綿延成千上萬行代碼的事並非前所未見的。這些超重app的突出狀況包括：厚重的View Controller很難維護（因爲其龐大的規模）；包含幾十個屬性，使他們的狀態難以管理；遵循許多協議（protocol），致使協議的響應代碼和 controller的邏輯代碼混淆在一塊兒。厚重的view controller很難測試，不論是手動測試或是使用單元測試，由於有太多可能的狀態。將代碼分解成更小的多個模塊一般是件好事。

二、遺失的網絡邏輯

蘋果使用的MVC的定義是這麼說的：全部的對象均可以被歸類爲一個model，一個view，或是一個controller。就這些。那麼把網絡代碼放哪裏？和一個API通訊的代碼應該放在哪兒？

你可能試着把它放在model對象裏，可是也會很棘手，由於網絡調用應該使用異步，這樣若是一個網絡請求比持有它的model生命週期更長，事情將 變的複雜。顯然也不該該把網絡代碼放在view裏，所以只剩下controller了。這一樣是個壞主意，由於這加重了厚重View Controller的問題。那麼應該放在那裏呢？顯然MVC的3大組件根本沒有適合放這些代碼的地方。

三、較差的可測試性

MVC的另外一個大問題是,它不鼓勵開發人員編寫單元測試。因爲view controller混合了視圖處理邏輯和業務邏輯，分離這些成分的單元測試成了一個艱鉅的任務。大多數人選擇忽略這個任務，那就是不作任何測試。

四、定義模糊的「Manage」

以前我提到了view controller能夠管理試圖的層次結構；view controller有一個「view」屬性，而且能夠經過IBOutlet訪問視圖的任何子視圖。當有不少outlet時這樣作不易於擴展，在某種意義 上，最好不要使用子視圖控制器（child view controller）來幫助管理子視圖（subview）。

要點在哪？驗證用戶輸入的業務邏輯應納入controller仍是model呢？

在這裏有多個模糊的標準，彷佛沒有人能徹底達成一致。貌似不管如何，view和對應的controller都牢牢的耦合在一塊兒，總之，仍是會把它們當成一個組件來對待。

總結一下MVVM：

在MVVM裏，view和view controller正式聯繫在一塊兒，咱們把它們視爲一個組件。視圖view仍然不能直接引用模型model，固然controller也不能。相反，他們引用視圖模型view model。

view model是一個放置用戶輸入驗證邏輯，視圖顯示邏輯，發起網絡請求和其餘各類各樣的代碼的極好的地方。有一件事情不該納入view model，那就是任何視圖自己的引用。view model的概念同時適用於於iOS和OS X。（換句話說，不要在view model中使用 #import UIKit.h）

因爲展現邏輯（presentation logic）放在了view model中（好比model的值映射到一個格式化的字符串），視圖控制器自己就會再也不臃腫。當你開始使用MVVM的最好方式是，能夠先將一小部分邏輯放 入視圖模型，而後當你逐漸習慣於使用這個範式的時候再遷移更多的邏輯到視圖模型中。

使用MVVM的iOS app是高度可測試的；由於view model包含了全部的展現邏輯而且不會引用view，因此它能夠經過編程方式充分測試。雖然有衆多的hack技術參與到測試Core Data模型，但使用MVVM寫的app能夠進行充分的單元測試。

以個人經驗，使用MVVM會輕微的增長代碼量，但整體上減小了代碼的複雜性。這是一個划算的交易。

再看一下MVVM那張圖：

回過頭再來看MVVM的圖示，你會注意到我使用了模糊的動詞「notify」和「update」，而沒有詳細說明該怎麼作。你可使用KVO，就像MVC那樣，但這很快就會變得難以管理。事實上，使用ReactiveCocoa會是更好的方式來組織各個部分。

用如今流行的那個詞說就是 用人話講MVVM就是：

Model層是少不了的了，咱們得有東西充當DTO(數據傳輸對象)，固然，用字典也是能夠的，編程麼，要靈活一些。Model層是比較薄的一層，若是學過Java的小夥伴的話，對JavaBean（陌生的自覺參考上邊的圖片）應該不陌生吧。

ViewModel層，就是View和Model層的粘合劑，他是一個放置用戶輸入驗證邏輯，視圖顯示邏輯，發起網絡請求和其餘各類各樣的代碼的極好的地方。說白了，就是把原來ViewController層的業務邏輯和頁面邏輯等剝離出來放到ViewModel層。

View層，就是ViewController層，他的任務就是從ViewModel層獲取數據，而後顯示。

最後

放幾張 我從網上找的別人設計的MVVM的 框架 目前我也正在研究 具體是MVC好仍是MVVM好 仁者見仁智者見智，，，