選用Vue作MVC架構模式

關鍵詞 並行開發 代碼複用 關注點分離

• 目錄
  • 經典的MVC架構模式
  • 背景
  • 選擇Vue
  • 經典MVC回顧
  • MVVM架構模式
  • front MVC架構定義
  • 並行開發模式
  • 結論

經典的MVC架構模式

MVC架構模式是經典設計模式中的經典，是一種編程的方法論。具備高度抽象的特徵，經典MVC用簡單的定義體現出解決複雜通用問題的辦法，只有不斷思考和體會才能用來解決不一樣狀況下程序設計所遇到的問題。

MVC不能脫離具體的框架而獨自存在，把握抽象必須用具體；把握具體的內在結構和外在關係只能用抽象。

在前端領域中有表明MVC的Anguler、表明MVVM的Vue、和表明單向數據流的React都是很棒的前端框架，分別表明了一種具體的設計模式應用，在不一樣的應用場景中使用對了框架才能把這些框架的特性充分的發揮出來，若是隻是從字面上找對應，Anguler纔是MVC的表明，Vue顯然不是MVC的表明，爲何我要選用Vue來作MVC架構模式呢？ 下面就來講一下爲什麼這麼作。

背景

我所在的部門業務場景上是分客羣分產品的, 產品需求上迭代很是快，全場景一年要發佈120多個版本，技術架構主要考量如下幾點：

• 產品穩定性
• 多產品並行開發，支持4-10個產品線獨立開發部署
• 多產品公共功能可複用，保證開發效率
• 提高用戶體驗

技術架構自己的生命週期取決於業務的生命週期，好的架構模式應該是模塊化的，能夠針對其中的一個模塊來進行優化升級，延長技術架構的生命週期就會節約不少成本。

選擇Vue

• 1.足夠的小巧，輕量，關注點聚焦，不會干擾總體項目設計架構；同時也有全家桶來作關注點分離，須要更多能力時全家桶中有可選擇的項，減小從新造輪子。
• 2.上手成本低、開發效率也很高
• 3.Vue生態成熟和有龐大的開發者羣體

不選Angular的緣由： 我的角度仍是很喜歡Angular，但Angular也有一些問題， 如大版本發佈太快和變化太大；大而全，這是優勢也是缺點，缺點就是設計太重不利於每一個團隊根據實際狀況基於Angular來從新設計架構，換掉其中的一部分設計，也很難讓團隊成員理解和適應。

不選React的緣由： 因Facebook的開源項目React嵌入了競爭防止協議，留下比較大的法務隱患，17年9月內部就拋棄了React框架，已經使用Ract的項目也要限按期限改成其餘框架。即便後來FaceBook的開源協議有所改善，但這種事情仍是讓你們心留餘悸，不能再提了。

經典MVC回顧

MVC全名是Model View Controller，是軟件工程中的一種軟件架構模式，把軟件系統分爲三個 基本部分：模型(Model)、視圖(View)和控制器(Controller)。

是一種軟件設計典範，用一種業務邏輯和數據顯式分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在界面和用戶圍繞數據的交互能被改進和個性化定製的同時而不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

Model（模型） 是應用程序中用於處理應用程序數據邏輯的部分。一般模型對象負責在數據庫中存取數據。

模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。模型與數據格式無關，這樣一個模型能爲多個視圖提供數據，因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用，因此減小了代碼的重複性。

View（視圖） 是應用程序中處理數據顯示的部分。一般視圖是依據模型數據建立的。

視圖是用戶看到並與之交互的界面。MVC好處是它能爲應用程序處理不少不一樣的視圖。在視圖中其實沒有真正的處理髮生，無論這些數據是聯機存儲的仍是一個僱員列表，做爲視圖來說，它只是做爲一種輸出數據並容許用戶操縱的方式。

Controller（控制器） 是應用程序中處理用戶交互的部分。一般控制器負責從視圖讀取數據，控制用戶輸入，並向模型發送數據。

控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，因此當單擊Web頁面中的超連接和發送HTML表單時，控制器自己不輸出任何東西和作任何處理。它只是接收請求並決定調用哪一個模型構件去處理請求，而後再肯定用哪一個視圖來顯示返回的數據。

MVVM架構模式

MVVM模式是工程師在解決WPF應用程序開發複雜度時提出的解決方案，它實現了View和Model的自動同步，開發者不須要再手動的綁定輸入監聽和手動的將數據結果展現在view上，這就是雙向數據綁定的優點，後來Backbone、Vue等都是MVVM模式的前端框架。

ViewModel解決了View和Model之間轉換的開發效率問題。 可是ViewModel內部的複雜度又變成了新的問題，其中一個問題就是雙向數據綁定劣勢。在雙向數據綁定中，Model（能夠理解爲狀態的集合） 中能夠修改本身或其餘Model的狀態， 用戶的操做（如在輸入框中輸入內容）也能夠修改狀態。這使的改變一個狀態有可能會觸發一連串的狀態的變化，最後很難預測最終的狀態是什麼樣的。使得代碼變得很難調試。

爲了解決這個問題便有了後來的Vue 單向數據流的解決方案-Vuex。 在複雜度較高的業務上使用單向數據流來解耦View和Model的關係。

---

能夠看出經典MVC架構模式的重點是要解決業務邏輯複用和數據顯式分離，前端MVC本質要解決的仍是這兩點，不一樣的是前端用組件化和MVVM分別來解決業務邏輯複用和數據顯式分離，MVC、MVVM都要解決MV這兩層的的問題。先後端分離後、前端使用單頁應用就能夠完成用戶界面部分的管理，此時在前端架構中須要有一層來管理頁面切換這就是前端MVC的Controller控制層。

MVC和MVVM本質上這是兩種架構模式，是爲了解決不一樣場景遇到的開發問題。 二者解決的問題有類似之處，MVVM中的ViewModel和MVC中的Controller做用有些類似。用Vue框架的項目引入Vuex後ViewModel的做用被弱化，MVVM和單向數據流都沒法反映整個框架的架構模式。同時總體架構還要解決單頁應用等問題，更須要有一個準確的理論模型，從而選擇MVC架構模式來作項目架構更適合實際狀況。

front MVC架構定義

代碼庫結構圖

在業務層（不包括基礎組件）和經典MVC想比Front MVC的核心由Model變成了View。 View層的設計是重點，基礎組件儘可能使用組件特性和MVVM、避免過分設計形成層級複雜度變大；業務組件能夠用EventBus的方式來處理跨層級交互的問題。 Model層由Vuex來管理，Vuex適合數據量大而且函數集中處理，管理接口數據很合適；以便明確各類方式的最佳實踐範圍。

Model（模型） 是應用程序中用於處理應用程序狀態管理和數據交互的部分。主要由狀態管理Vuex和數據交互axios實現。

View （視圖） 是應用程序中業務邏輯處理和內容展現的部分。不一樣於經典MVC中的View，Front MVC的View層業務邏輯會比較重，這是因爲前端的複用主要體如今組件上，前端框架Vue的Global API一系列特性也很是好的支撐這種組件化業務需求。這裏的View層主要有基礎組件庫、公共組件庫、產品組件庫組成，其中前兩個庫是能夠複用的。

Controller（控制器） 是應用程序中處理用戶交互的部分。 不一樣於MVC中的Controller， Front MVC的Controller層是經過路由機制加載View主要是有viewRouter來實現，再有View根據交互邏輯來控制Model層的調用。在這裏View是應用程序的核心部件。

這樣設計的特色：

• 首先實現了單頁應用，用戶體驗交回前端管理
• MVC各層是模塊化的，可靈活調整和複用
• 層級劃分清晰，利於用最佳實踐實現
• Model層數據可複用，跨頁面公共數據根據狀況可只調用一次
• View層可複用

並行開發模式

並行開發效率高，但產品多、開發人員多、發版頻繁必定會形成衝突和相互影響，必須重點關注保證產品穩定性。控制好公共部分的改動頻率和修改權限。

解決方法：

• 各產品庫的node_module依賴項統一管理，兼容公共部分依賴項。
• 業務公共庫各產品負責人有修改權限，既保證公共部分協同開發，也保證公共部分穩定。
• 基礎組件庫精心打磨，控制發版頻次。
• 只在產品庫中編譯項目,公共庫使用git sub module的方式引入，各產品單獨發佈部署包。
• 各產品單獨部署。

結論

只要能解決問題，架構應該是越簡單越好，就像經典MVC架構模式同樣簡潔，同樣有力量。不斷總結分析，尋求不一樣的解決方法，設計時總體考量，常常在抽象和具體以前切換角度思考，才能兼顧開發效率和技術支撐。

---

本文是從項目總體設計上對MVC架構模式進行了一個實踐總結，歡迎你們交流指正！