MVVM的兩三事

MVVM是什麼 ? 能吃嗎 ?

在做軟體開發的時候，常常會使用一些設計模式去做系統架構的開發與設計，像是常見 Model-View-Controller (簡稱 MVC )、觀察者模式、代理模式等等，透過這些設計模式，更能有效的使我們的軟體架構增加可讀性以及擴充性。

那 MVVM 又是什麼呢 ? 在 iOS/Android 的開發中，我們遵循的是最常見的 MVC 開發模式，在 iOS/Android 中，通常 Stroyboard/Xib/Xml 為我們的 View 層級，負責作為顯示跟介面上的邏輯，ViewController/Activity/Fragment 做為 Controller 層級，Model 則為存取資料的層級。

不過常常我們會需要在 ViewController/Activity/Fragment 當中去操作對 View 的相關處理，而不光是只控制 App 的流程及邏輯，那是因為不管在 iOS/Android 的設計中，ViewController/Activity/Fragment 也被用來當成 View 的一部分，由於模糊不清的權責，讓我們常常寫出一個極致複雜的 Controller 類別 - Massive ViewControler 。

為了解決這個問 題，有許多人提出了各式各樣的 MVC 變形設計去解決，而 MVVM 就是其中的一種。

Model-View-ViewModel

其實在 iOS/Android 當中，不管是 UIViewController 或是 Activity 其實他們真正的權責劃分都應該是屬於 View 層級的一部分。如上圖所示，接下來我們就要來討論真正的主題 - Model-View-ViewModel ，我們先看一下下面這張圖。

這張圖很清楚的告訴我們，每個層級所代表的權責範圍與溝通方式 :

• View : 顯示 UI 以及畫面上關於 UI 的操作。
• ViewModel : 處理應用程式中的邏輯以狀態，並且持有與改變資料。
• Model : 處理資料。
• 溝通方式 : 透過觀察者模式以及 Databinding 的機制，讓 View 的事件傳遞到 Controller 獲取資料後即時通知View需要改變。

所以我們現在就可以將視圖控制所需要的代碼寫在真正我們所定義的 View 層級 (UIViewController/UIView/Xib/Stroyboard in iOS) ，而將邏輯以及狀態相關的代碼寫在了我們的 ViewModel 層級，這樣一部分可以解決 ViewController 過於臃腫的問題，也因為權責歸屬相對的清楚明暸，在未來的擴充與協作上也更充滿了彈性。

進階思考

其實在工作中寫了將近大半年的 Mvvm ，中間也遇到了對於 Mvvm 的不求甚解，像是當每一個 UITableViewCell 是否需要各自的 ViewModel 對應，ViewModel 的生命週期應該相依於 UIViewController 或者其他元件上嗎 ? 該如何讓 View 與 ViewModel 綁定，資料的流向，視圖跳轉的邏輯應該由誰負責，這些問題都是相對的令人困惑，在設計上也因為這樣子而走了很多遠路，那在之後我們會根據這些實際開發遇到的問題一一來做探討與解說。