今天公司的測試服務器開小差了，後臺被吐槽的體無完膚，雖然我們都知道跟他沒有什麼關係，但是生活需要樂趣，總要有人背鍋，哈哈！~~~暫時沒有環境開發了，那就分享一下之前做的一篇關於Android開發模式的總結，MVC，MVP，MVVM對於剛瞭解或者沒有好好歸納總結的朋友來說，特別是那些像我記性很差的朋友來說，很容易忘記。
下面我們一起歸納總結一下，這樣屢清楚他們的關係我們用起來就可以迎刃有餘，也不會再面試的過程中遜色於那些背書黨了。畢竟我們是屬於行動派的：
不知道爲何我會想起一個成語叫：萬佛朝中，好吧，就用這個來做標題吧
目錄
錯誤四：Model 層依賴 Presenter/ViewModel 層
萬佛朝中MVX（MVC、MVP、MVVM）
MV-C
MV-P
MV-VM
實際上就是MVx（x=C,P,VM...），下面我們通過幾個常見的誤區來說明這些框架的原理。
常見問題
1、實際關係是：M（業務邏輯）和VX（表現層邏輯），並不是M、V、X並立的
錯誤一：VX層處理業務邏輯，做了M層的工作！
V層：
負責發送用戶操作給X層
負責接收X層傳來的控制
X層：
處理幾乎所有的表現層邏輯。（爲什麼？這樣方便進行單元測試）
M層：
Model 層包含了業務數據
以及對業務數據的操作 (behaviour and data)
錯誤二：Model就是靜態的業務邏輯數據
我們做業務模塊開發時，會經常定義一些數據結構，比如User類、Order類等Bean類。只有一些簡單的get和set方法。有人認爲這樣的數據結構就是Model。一個數據結構實例沒有行爲，連對象都稱不上，怎麼能代表 Model 層呢！
靜態的業務數據不能代表 Model 層，業務數據以及針對業務數據的操作共同構成了 Model 層，這也就是業務邏輯。
所謂的（與表現層VX邏輯區別的）業務邏輯處理就是網絡請求、數據庫查詢等數據獲取邏輯，即Model層就是負責數據獲取的，這也是我要說的第三個錯誤觀點。
錯誤三：Model 層就是負責數據獲取的
業務邏輯層並不負責數據的獲取，數據的獲取職責還要在 Model 層的更下層，這也是爲什麼我要把的 BlogModel 的實現邏輯寫得如此簡單，因爲數據獲取的職責全部交給了 BlogFeedRepository 類，Model 層只處理業務邏輯。
BlogFeedRepository 是博客列表的倉儲類，BlogModel 通過 BlogFeedRepository 的 fetch() 方法獲取標籤爲 recommend 的博客列表，也就是推薦的博客列表。
錯誤四：Model 層依賴 Presenter/ViewModel 層
實際上應該是 Presenter/ViewModel 通過接口的形式依賴 Model 層，Model 層完全不依賴 Presenter/ViewModel。就像我前面的示例代碼裏一樣，Model 層必然不會出現任何 presenter 這樣的單詞，上層通過觀察者模式來監聽 Model 層的數據變化（ LoadCallback 接口也算是一種），Model 層也不用關心上層是 Presenter 還是 ViewModel。
總結：
其實關於 MVX 還有更多可以討論的，比如有些人認爲 Model 層並不是真正處理業務邏輯的地方，它只是業務模塊的一個上層封裝層（下面包含真正數據獲取，業務邏輯處理就是網絡請求NetWorkDataReponsity、數據庫查詢SQLDataRepository 等數據獲取邏輯），我覺得也不無道理，在複雜業務模塊中，業務是存在層次的，MVX 中的 Model 層是所有業務層中的最上層。
還有我剛剛提到的業務層之下還有數據層，這是典型的三層架構的概念，即表現層、業務層和數據層。邏輯存在分層，所以架構也必然要進行分層，MVX 可以做爲我們從代碼到業務甚至到架構的探索的開端。