關于MVVM的一些思考

? 尋找mvvm相關資料已經找了很長時間了，簡書，掘金，CSDN看了很多各路大神洋洋灑灑幾千字的文章，但最終都沒有找到我所想要的架構設計，大多數文章先在介紹MVVM的起源，然后介紹關于DataBinding框架的一些使用方法。

? Shit！我要看這些干嘛！因為既然想到MVVM模式，那肯定是經過標準安卓設計模式（且這么說，否則沒有用到設計的某些程序，都自稱自己是MVC），再經過MVP模式，最終會選擇MVVM這個模式。So，DataBinding這個框架我已經默認你會了，不過確實不難，用熟了會很爽。

? 為什么要使用MVVM？有人說，我不喜歡MVVM，因為把邏輯寫在XML里面讓人看的不夠清晰，但是看到這樣的代碼你會說不清晰？

<TextView android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="@{user.name}"/>

      <TextView android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="@{user.nick}"/>

? 這樣的代碼明顯比你那個findViewById再setText強的太多，User在變，TextView跟著再變，感覺這里的邏輯就是那么順理成章。有些人說我有ButterKnife不需要findviewById了，但是ButterKnife的效率貌似不高（查閱了相關資料，沒有去做實驗），但是DataBinding可不一樣，Google自家開發的框架，AndroidStdio原生支持，XML語法高亮，方法跳轉等等，更為重要的是DataBinding是一次性生成布局的樹狀結構，對于XML中添加Id的控件，即可以直接以final成員的方式訪問，不會重復findViewById，傻傻的從根節點尋找。hi！兒子，你是某某Id的view嗎？不是啊，那你問問你兒子看。。。

? 那怎樣的設計會比較完美呢？在做的這個項目，結合老大哥留下的代碼我也做了很多嘗試，MVPVM，這應該是他的嘗試，這個名詞在翟一凡的博客中好像也看到過，我在原有代碼的基礎上進行了自己的改造，M層處理數據的來源，V層是架在Fragment上，處理界面的變化，P層處理網絡請求，去調M層的數據，VM這個層是好layout綁定在一起，我當時的設計是這樣的，一個界面一個VM，即使這個界面上面是一個Banner圖，中間是幾個選擇菜單，底下是一個縱向的列表，我是一個界面一個VM的形式寫的，在Presenter和ViewModule這兩個層可以不導入android包中的任何一個類，與其他Activity交互也都是在View中進行的，s寫的也是十分的舒服，項目上線后，我又在思考這個設計的問題，因為模式而模式，導致了0復用，類太多，一個界面下面至少有xxxContract，xxxPresenter，xxxViewModule，xxxFragemnt，顯然這不是我所看到的。后來在github上面找到一個示例 archi ，start的人還蠻多的。這個示例介紹上面提到的安卓的三種設計，主界面是列表，次界面是詳情。大多數App都有這個設計吧，原諒我蹩腳的截圖，排版排不好，將就一下。

? 然后是這個是類的結構，分了m，v，vm三個包。

? 在這個設計里面，V層的接口寫在VM中，然后每個View對應一個VM，其實現在想來，應該是這樣設計的，MVVM，視圖和模型綁定，那么每個視圖綁定一個一個VM進行綁定，VM這個層完全可以取代掉Presenter這個層，也不需要Contract，因為Contract的存在就是關聯P和V，這樣處理的好處就是，各個View之間可以解耦，舉個例子，可能存在多個界面用到Banner，但是ViewModule不需要動，變化的只是其中的數據而已，再說點擊Banner的跳轉事件，以前是寫在View層的，因為我的VM中是不含有Context的，但是從archi這個示例看來，他點擊列表中的Item跳轉事件都直接寫在VM中，那么我們的banner完全也可以把點擊跳轉寫在VM中，這下好了，只需要關心數據，剩下的都交給他吧。

? 近兩年Android涌現出好多新的框架，新的東西帶來新的挑戰，學習的曲線是陡峭的，但是學會之后開發效率也是可以提高數倍！

來自：http://www.jianshu.com/p/f7a9d9732fcb