?這些年，參與的項目大大小小應該有六七個。所采用的項目架構，也是從 MVC 到 MVP ，后來使用 ReactNative 進行跨平臺開發，再到后來回到原生，使用 MVVM。本節，打算聊一聊我的項目架構的演變之路。
MVC
?M, Model，主要負責進行數據訪問，產生數據；C，Controller，主要負責對接 View 和 Model，將 Model 反映到 View 上，或者響應 View 上的動作，修改 Model，處理業務；V，即 View，主要負責 UI 渲染。
?上圖來自維基百科。我們可以看到一個典型的 MVC 模式下的數據流向。上圖中，View 監聽 Model 的數據變化，然后進行 UPDATES 工作，這其中也會有業務邏輯處理。事實上，有些時候我們還需要對 Model 層的數據做進一步處理然后再做前端展示，這也是部分業務邏輯。
?所謂架構只是一種設計理念，目的就是在于保持邏輯的清晰，面向改變易擴展，功能易復用。對于 MVC 模式而言，看上去各司其職，請求數據的產生數據；負責邏輯的處理邏輯，負責渲染的進行渲染，清晰明了。
?然而，View 層對 Model 有著很強的依賴。為了能夠使得 Model 發生的變化及時反映到到 View 上，View 需要注冊成為觀察者到 Model 上。鑒于這種關系，View 、 Model 需要互相持有對方的引用。
?首先，這種相互持有引用會導致層次的獨立性、可重用性要降低一些，而且這種行為也是危險的，暴露更多的能力給 View，可能使得部分本應在 Controller 處理的邏輯放在 View，因為這樣做確實更加快捷方便。這樣做也會帶來一個很嚴重的問題：View 會客串 Controller 的角色，從而越來越臃腫，解耦能力越來越弱。
MVP
?使用 MVC 沒多久，同事建議組長采用 MVP 開發模式，于是，就是這么快的就跳轉到了 MVP 的陣營。當時最感興趣的還是這種架構中突出的對接口的應用，面向接口的編程思想。
?面向接口的編程，實際上是 Java 開發一直所倡導的。優勢在于解耦，降低依賴關系。但是也會讓開發工作更加復雜。
?上圖同樣來自維基百科。相較于 MVC 模式，它切斷了 View 層和 Model 層的直連。Model 和 Presenter 之間， Presenter 和 View 之間相互暴露接口，并通過接口相互訪問，接口構成了它們通信的通道。與 MVC 類似， Modle 負責數據訪問和處理；Presenter 像膠水一樣，把 Model 和 View 綁在一起，它主要處理業務邏輯，對 View 提供處理好的數據，對 Model 請求數據；View 處理 UI 渲染。
?后來的開發過程中，很少使用 MVC，當然并不是因為覺得它比 MVP 差。更多的，自己是想增強接口使用的意識，以及對新事物的一種探索欲。現在想想，其實它們更多的是理念上的不同，如果控制的足夠好，各有千秋吧。下面我們就來比較一下。
MVC vs MVP
?這兩種結構，都體現了良好的解耦理念。將一個需求拆分成數據訪問模塊、UI渲染模塊、業務處理模塊，相對獨立，分工明確，各謀其政。同時，各個模塊之間又可以在一定程度上相互組合，盡可能地進行功能復用。但是，在具體使用上，我覺得還是有一些偏好。
?保證結構的清晰是一件非常重要的事，對此，大多數情況下寧愿犧牲性能。這一點上我認為 MVP 要比 MVC 做的好，職責劃分的更加清晰。Activity 只負責渲染，很清爽；當然，這就意味著更多的處理邏輯需要搬到 Presenter 中去；Model 只負責向 Presenter 提供數據支持。為了保證邏輯的清晰，整個過程卻會顯得復雜，有些地方甚至沒必要。View 層明明只是需要改一下 Model 的數據，都需要 Presenter 代勞。顯然，這種清晰性犧牲了高效。
?結構上的清晰，職責上分工更加明確，更細，也應該就意味著更好的復用性，更加靈活。但是，同樣這也未必總是需要的。如果一個需求交互不多，Presenter 可能就會非常小，又何必將一個文件能夠搞定的事一定要分成三個文件去完成？
MVVM
?MVVM 是由 MVP 演化而來的。我覺得它主要解決了 MVP 沒有很好解決的兩個問題：
- 對于 MVP 的 Presenter 層，由于要處理所有業務邏輯，又要完成 Model 和 View 的溝通，最終可能也會非常臃腫。
-
通常情況下，我們總是要通過 findViewById 找到控件，然后進行數據填充，如果一個頁面很復雜，需要填充的數據很多，這樣在 View 層會顯得很不優雅。
?這樣，就交給 MVVM 來解決吧。
MVVMPattern
?上圖（來自維基百科）中很好的解決了這兩個問題。ViewModel 集合了 Presenter 的能力，同時兼顧了 View 需的數據基礎。它將數據直接綁定到 View上，這種綁定是一種雙向綁定，即數據的變化會自動導致 UI 的刷新，而 UI 上的動作，同樣會自動調用響應的綁定的函數修改數據。
?Android 所提供的 DataBinding 技術很好的體現了這一點。之前翻譯過一篇官網上關于 DataBinding 的介紹，感興趣的可以看一下。現在 View 層可以更加清爽，不用再為了填充數據而找出所有的 View，一個一個填充，而 View 也會由于某個用戶動作而自動回調修改數據，這一切都是自動完成的。當然，有利必有弊，這種框架的使用，首先需要我們去了解它的特性；而且自動完成，未必會有我們手動完成效率高，多半會犧牲部分性能。
小結
?架構， 一種理念，一種思想，一個工具。它的目的，旨在幫助我們更好地面對、處理變化；更加清晰地認知我們正在做什么。
?工具是有了，這只是一個基礎。更為關鍵的我覺得還是對這種工具的把控能力。因此，也并非是說你使用了 MVVM ， 你的項目應對變化的能力就一定會比 MVC 好。對于需求的理解，將需求進行抽象的能力，以及對于技術扎實的能力，這些都將會對架構的把控提出挑戰。
