MVVM(Model-View-ViewModel)介紹

8.1 分離用戶界面和業務邏輯

在開發應用程序時，要把用戶界面和業務邏輯分離開來，這是每個程序員都知道的常識。分離用戶界面和業務邏輯有幾個重要的好處：

有利于隔離變化。用戶界面是最容易變化的，易用性的改進，外觀的美化和需求的變化，首先沖擊的就是用戶界面。如果用戶界面和業務邏輯耦合到一起，界面上一點微小的改動都會導致一系列代碼的修改，這不但會增加開發的成本和周期，而且這種改進也是很無趣的，讓程序員的幸福感直線下降。

有利于自動測試。代碼中的BUG，越早被發現，修改的成本越低，而單元測試是在早期發現BUG的重要手段。單元測試是自動化的，前期編寫測試代碼的投入，會因為后期節省測試的時間而獲得回報。單元測試代碼可以不斷積累，為軟件構建一道堅固的防火墻，讓整個系統越來越穩定。分離用戶界面和業務邏輯是提高代碼可測試性的重要手段，讓編寫單元測試程序成為可能。

有利于分工合作。用戶界面和業務邏輯的耦合，會讓用戶界面的修改很困難，程序員就會抵觸用戶界面的改動，讓設計師和程序員之間的矛盾加大。分離用戶界面和業務邏輯后，設計師的工作成果可以平滑的輸出給程序員，讓程序員和設計師一起過上共同幸福的生活。

8.2 如何分離用戶界面和業務邏輯

分離用戶界面和業務邏輯，MVVM是目前最常用的模式。MVVM并非憑空出現，而是由MVC和MVP一路演化而來的，每次演化都是為了解決之前沒有解決的問題。

8.2.1 MVC模式

MVC是Model-View-Controller簡稱，它首次把系統分成Model，View和Controller這三部分，明確的把用戶界面和業務邏輯分離開來：

• 模型(Model)。簡單的說，模型就是業務邏輯。我們經常說面向對象的設計和建模，所建立的模型就是這里的模型，是對現實世界中業務邏輯的抽象。面向對象的建模，就是要找到業務邏輯中有哪些類以及這些類之間的關系。類描述了對象的屬性和行為，類是設計時的概念，對象是運行時的概念。對象通常就是業務實體，Model包含一個或多個業務實體。很多人(包括國內一些知名的專家)認為模型就是數據，這是沒有透徹理解面向對象的設計導致的，對象是即有數據又有行為的，光有數據沒有行為，就無法讓對象之間協作，無法共同完成業務邏輯。
• 視圖(View)。這個是大家都知道的，就是用戶與軟件交互的界面，對于GUI應用程序來講，就是窗口和對話框，以及上面的各種控件。視圖應該說是為用戶提供了一個界面，讓用戶可以觀察和操作模型。
• 控制器(Controller)。控制器負責解釋來自用戶通過鍵盤/鼠標等設備的輸入，并通知模型和視圖做出相應的改變。在GUI應用程序中，直白的說，其實就是控件的事件處理函數，它與界面相關和模型都相關，它從界面獲取數據，然后調用模型的函數，有時還會直接更新用戶界面。

控制器(Controller)不是業務邏輯，理論上只是很薄的一個膠合層，但是很多新手把業務邏輯寫在控制器里，導致模型只剩下數據了，讓人產生控制器就是業務邏輯，模型就是數據的錯覺。

8.2.2 MVP模式

MVC模式解決分離用戶界面和業務邏輯的問題，但是還有一個重要的問題沒有解決： 控制器是界面相關的，沒有辦法為控制器編寫單元測試程序。為了解決上面的問題，MVP模式應運而生。MVP是Model-View-Presenter簡稱。

• 模型(Model)。模型還是MVC中的模型，這里不再贅述。
• 視圖(View)。視圖還是MVC中的視圖，但它不需要向模型注冊改變的事件通知了，這個由呈現邏輯去做了。
• 呈現邏輯(Presenter)。Controller變成了Presenter只是表面現象，最重要的是MVP對視圖進行了抽象，呈現邏輯不再向控制器那樣直接訪問具體的視圖了，而是通過視圖的接口去訪問視圖，視圖的接口是抽象的，可以有不同的實現，所以可以方便的Mock出一個視圖，讓編寫呈現邏輯的單元測試程序成為可能。注意，這里視圖的接口并不是通用的，每個視圖都有一個獨立的接口，有一個真正的實現和一個用于測試Mock的實現。

從理論上講，MVP模式已經很完備了，它很好的分離的界面和實現，也可以為呈現邏輯編寫單元測試程序了。但是從工程角度來看，MVP卻有一個非常致命的缺陷：要編寫大量無聊的代碼！

為了方便說明，我們以一個編輯圖書信息例子，看看要寫哪些無聊的代碼。這個例子非常簡單，卻要寫不少無聊的代碼：

• 1.初始化的時候，要為控件注冊事件處理函數，比如為『保存』按鈕注冊事件處理函數。
• 2.初始化的時候，要把圖書信息，如書名、作者和出版社等信息從模型中取出來，一個一個的設置到視圖的控件中去，在這個過程中，可能需要對數據格式進行轉換，比如出版日期，在模型中是一個整數，在視圖上表現為一個字符串，這就需要轉換。
• 3.在編輯結束時，要從視圖中把圖書信息，如書名、作者和出版社等信息一個一個的取出來，再保存到模型中去。在這個過程中，可能需要對數據格式進行轉換，比如前面的出版日期，要把視圖中的字符串轉換回模型中的整數。
• 4.View都有一個接口定義，有一個真正的實現和一個Mock的實現。

這些代碼很簡單卻很無聊，在每個有界面的模塊中，都遵循同樣的規律，卻又完全不同，不得不重新編寫。

8.2.3.MVVM模式

把MVP模式這些規律找出來進行抽象，通過一些規則在視圖和模型建立聯系，也就是數據綁定和命令綁定，就形成了MVVM模式。MVVM是Model-View-ViewModel簡稱。在MVVM中：

• 模型(Model)。模型還是MVC中的模型，這里不再贅述。
• 視圖(View)。視圖還是MVC中的視圖，但它不需要向模型注冊改變的事件通知了，這個由數據綁定去做了。
• 視圖模型(ViewModel)。 ViewModel不是Controller也不是Presenter，視圖模型是視圖還是模型？按MVVM的發明者John Gossman的話說，視圖模型是視圖眼中的模型。放大鏡下的蟲子還是蟲子，所以視圖眼中的模型還是模型。視圖模型與視圖沒有直接關系，是可以為之編寫單元測試的。

呈現邏輯Presenter去哪里了？呈現邏輯從一行行代碼變成了一條條數據綁定和命令綁定的規則，對規則的處理和解釋成了MVVM框架或公用庫，可以在多個項目中共享。

MVVM模式有下列好處：

• 強制分離用戶界面和業務邏輯。在MVC和MVP中，不能強制分離用戶界面和業務邏輯，程序員的一念之間，就導致用戶界面和業務邏輯混在一起。MVVM中不需要編寫界面相關的代碼，自然沒有辦法讓用戶界面和業務邏輯耦合到一起。
• 界面描述文件和程序代碼之間具有更松的耦合。通常用XML或RC文件來描述界面，在MVC和MVP中，在界面上增加一個控件或刪除一個控件，都會導致相應的代碼需要修改。而在MVVM中，采用了面向意圖的編程，界面上表現的只是一種意圖，至于在程序中，誰去實現，怎么實現，甚至有沒有實現，界面都是不關心的，所以界面和代碼之間值的耦合是很松的。
• 不需要學習GUI的API。通過數據綁定和命令綁定建立視圖和模型之間的聯系。用聲明式的規則取代命令式的代碼，不需要寫界面相關的代碼，所以不需要學習GUI的API，無論是采用Qt還是AWTK，都用同樣的方式開發。

視圖模型和模型并不相同，之所以要引入視圖模型，主要原因有：

• 模型中的數據有時并不適合直接顯示在視圖上。比如出版日期，在模型中是整數，直接顯示出來，用戶就看不懂，需要轉換成人類可以理解的字符串。
• 模型中的一個數據項可能以多種形式呈現在視圖上。比如出版日期，除了顯示出版日期外，也可能把最近出版的書，顯示一個新書標志。
• 視圖中的輸入數據和模型中的存儲數據，它們的格式有時可能不同。比如出版日期，視圖上輸入的格式和模型里存儲的格式就不一樣。
• 視圖需要視圖模型提供數據校驗規則來判斷視圖上的輸入是否合法。
• 有些數據是有依賴關系的。比如在輸入收貨地址時，選擇省份時，城市列表跟著變化。
• 有些狀態不屬于業務邏輯，但是需要保存下來。如為了支持撤銷操作，需要保存命令歷史記錄。
• 在C/C++等靜態語言中，沒有辦法通過函數的名稱去調用對象的成員函數，也沒有辦法通過屬性的名稱去訪問對象的成員變量。視圖模型需要提供一種機制來實現這些功能，否則綁定規則就沒法實現。

MVVM 的缺點。

• 內存問題。據說WPF內存開銷很大，即使在PC上也大得讓人無法忍受(常有人借此來反對MVVM)。WEB前端流行的MVVM框架，像React和Vue.js等，采用虛擬DOM的方式，內存需求可能有大幅度增加。
• 性能問題。MVVM通常的做法是，模型有變化時會刷新整個界面。如果采用虛擬DOM的方式，還需要重新構建一個虛擬DOM，與原來的虛擬DOM比較，性能開銷就更大了。
• 調試問題。如果沒有工具的協助，數據綁定會讓調試變得困難。

以上這些問題在手機和PC上，已經不是什么大問題了，但對于嵌入式系統來說，仍然是難以跨越的障礙，所以目前幾乎沒有針對嵌入式平臺開發的MVVM框架。

8.3 AWTK-MVVM

AWTK-MVVM是一套用C語言開發的，專門為嵌入式平臺優化的MVVM框架。它實現了數據綁定、命令綁定和窗口導航等基本功能，使用AWTK-MVVM開發應用程序，無需學習AWTK本身的API，只需學習綁定規則和模型的實現方式即可。

與其它MVVM框架相比，AWTK-MVVM特點有：

• 代碼小。
  • 核心代碼：約3000行。
  • AWTK相關代碼：約700行。
  • jerryscript相關代碼(可選)：約1700行。

• 性能高。核心代碼用C語言開發，其性能與直接使用AWTK差別不大。
• 內存開銷小。
  • 一條綁定規則大概需要150字節。一個窗口上若有10條綁定規則，內存占用了也就1.5K。
  • 列表中的綁定規則可以共享，額外增加的內存開銷，比例也是很小的。

• 隔離更徹底。在AWTK-MVVM中，界面和綁定規則在XML中描述，開發應用程序時只需要開發模型(也就是業務邏輯)即可。除非通過特殊手段，開發者沒有機會直接去訪問視圖。
• 易調試。
  • 提供視圖模型的框架生成工具，避免手寫代碼造成的錯誤。
  • 增加了各種異常處理的LOG信息。
  • 提供大量的demo以供參考。
  • 開放源碼，調試方便。

• 支持多語言開發。
  • 目前支持C語言和JS。
  • 以后會根據需要支持新的編程語言。

這里支持的多種編程語言與AWTK的腳本綁定是完全不相關的概念：這里是讓應用程序的業務邏輯可以用不同的語言來開發，而AWTK的腳本綁定是讓應用程序可以使用不同的腳本語言來調用AWTK的API。

• 可移植到其它GUI。AWTK-MVVM是為AWTK設計的，但是我們隔離了與AWTK相關的代碼，讓它可以移植到其它GUI。AWTK相關的代碼僅僅700來行，可見移植到新的GUI是非常容易的事情。當然，AWTK可以滿足常見的需要，這樣做只是給開發者提供更多選擇。

AWTK-MVVM也有些限制，目前不支持界面元素動態生成，這時可以結合傳統的方法開發。以后AWTK會支持WEB前端流行的框架如Reactjs和Vuejs，在高端平臺(如手機、小程序和桌面程序)中應用。

在后面的章節中，我們將詳細介紹AWTK-MVVM的具體用法。

總結

以上是生活随笔為你收集整理的c# mvvm模式获取当前窗口_AWTK-MVVM 介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。