為什么要MVC

2019-11-17 03:53:09

字體：大中小

來源：轉載

供稿：網友

最近在公司寫了一大堆復雜的界面，終于體會到了前輩們那種上刀山下火海的感覺了。做完了之后回頭想想，MVC還是有道理的。

    什么是MVC？其實可以簡單的理解為一個有UI的程序可以劃分為三個部分：數據層、邏輯層和應用層。當然這些名字是我亂起的。數據層顧名思義就是用來讀寫數據的地方，譬如說一個電話本的文件。邏輯層就是用戶在界面上的操作的抽象，譬如說要通過名字來查找消息啦，給一個關鍵字求得篩選后的電話信息列表啦。應用層指的就是那一堆控件了。MVC三個字母分別指的是Model、View和Controller，也就是模型、視圖和控制器了，分別對應于數據層、應用層和邏輯層。

    以前在看MVC的時候總是被一些教條主義的東西迷惑，說什么在MVC里面，MV解耦，所以M可被替換，V也可被替換。這個時候往往會感到迷惑。為什么模型，或者說數據層要被替換？為什么視圖，或者說界面要被替換？其實這在一個不是復雜到神級級別的程序里面是不會發生的。但是MVC并不是為了讓你能夠實現模型被替換或者試圖被替換而產生出來的，我覺得這個模式（其實這不是設計模式的其中一項，真的）更加重要的特點是可以讓你的程序寫起單元測試來更加容易。

    還是電話本，現在有一個要求，說在輸入人的名字之后，只要系統檢查出你超過0.5秒沒有持續輸入，那么底下的列表就會自動根據你上面的輸入進行篩選。其實這有點像Outlook。這要怎么寫單元測試？我們知道雖然正規的測試會有一大堆用來自動完成界面操作的工具啊，或者類庫，但是作為單元測試來講我們并不需要去做這種事情。因為單元測試是程序員寫的，凡是程序員寫的東西當然是需要盡快得到結果的。一般的開發方法是寫一點代碼，寫一點測試，跑，有bug改沒有bug繼續。我們在開發程序的時候會不斷地、頻繁地跑單元測試，來看看我們的東西是不是有問題，或者在重構的時候我們對于我們的代碼正確的信心會大一點。

    那界面怎么辦呢？難道我們真的要去引入一個庫來搞界面的自動測試嗎？當然想要也可以，不過這畢竟太復雜，而且這一類的工具的穩定性其實都不是特別好，被誤導的幾率倒是大增。這僅僅是對于程序員來講的，當然搞測試的那些人自有他們的辦法。那既然我們不做界面的自動測試那怎么知道文本框被輸入之后究竟篩選出來的數據對還是不對呢？

    答案：MVC。

    為什么View，也就是試圖，也就是界面，可以被替換是一件很重要的事情？想一想，如果控件可以被換成單元測試的一段代碼，那豈不是很爽么？舉個例子，我們要告知用戶說，我們的事情已經做了一半了，這個時候我們可能會去設置進度條的位置。但是“告訴用戶說我們的事情已經做了一半”跟“設置進度條的位置”其實是完全無關的兩件事情。因此我們的Controller要負責通知View說事情做了一半了，然后View就可以去設置進度條的位置了。現在我們把View換成單元測試的一段代碼，這個時候就變成Controller通知測試程序說事情已經做到一半了，然后測試程序就會去檢查說現在是不是應該做到了一半，如果應該，顯然這個用例就通過了。

    那Model呢？Model可以簡單的理解為數據源，其實當然不只是那么簡單，不過這樣理解會讓我們更容易接受一點。數據源是什么，當你寫單元測試的時候，去連接一個數據庫來獲得數據源，然后就操作Controller，這個時候你如果不親自去讀一下數據庫，你怎么知道Controller給你的東西究竟是對的還是錯的？顯然Model我們也可以換掉，測試程序偽造數據成為一個Model，然后插入Controller，事情就解決了。數據是我們自己給的，那Controller應該提供什么我們也能知道了。

    于是，使用了MVC之后，單元測試想換Model就換Model，想換View就換View，測試什么就非常容易了。至于說用戶停止輸入0.5秒之后是不是會真的去進行數據的篩選，這個我們手工測試就好了，而且那些搞測試的人也會幫我們檢查的。

    好吧，說到這里有人可能會問為什么我沒有給出一個Demo？這東西太虛，實踐實踐自己體會一下就行了，而且MVC變形那么多，有Model-View-PResenter，還有最近興起的Model-View-ViewModel等等，其實現都跟傳說中的那個類似橋接模式的東西差別甚遠。這個自己去看一看就好了。

上一篇：Asp.Net大型項目實踐(7)-用Unity實現AOP之事務處理+為啥要用AOP（附源碼）

下一篇：我最近使用的一種CSS的重構思路