關鍵詞 並行開發 程式碼複用 關注點分離
經典的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架構模式進行了一個實踐總結，歡迎大家交流指正！