在MVVM分層之下
MVVM把一個系統拆分成檢視層、檢視資料層、資料訪問層：
但我們要搞清楚一點，MVVM是MVVM庫設計時所遵循的原則，而不是我們寫程式碼時應該遵循的。我們只是在MVVM分層下，分別在Model、VM、View這三個部分寫自己的業務程式碼。
因此，我們還需要找出一系列正規化，在基於MVVM的大流程下，指導我們寫出分層合理、可擴充的業務程式碼。
庫與框架
庫 + 正規化 = 框架
遺憾的是，由於缺少官方給出的一系列正規化，我們常用的React和Vue並不是框架。
幸運的是，我們還有Angular。
其實到這裡，我們可以直接去翻閱Angular的文件，然後取其精華，應用到自己的React或Vue的專案之中
Angular架構概覽：www.angular.cn/guide/archi…
自己發掘正規化
從後端說起
我們要知道前端工程化的歷史一共不過幾年，其中的積累必然沒有後端多，所以有一定的後端知識，對前端工程化開發是很有裨益的。
如果我們去看一個優秀的後端專案，我們的第一印象肯定是：哇，分了這麼多的層，而且每一層都做到了解耦，看起來很高大上的感覺！
這說明，後端的確有至少一個非常成熟的框架來指導後端業務程式碼的書寫。
後端是如何解耦業務程式碼邏輯的
在第一小節說過，我們的業務程式碼是位於在MVVM分層之下的，大量的業務邏輯程式碼會出現在VM這一層。對於後端來說，大量的業務程式碼也同樣會出現在MVC的Controller這一層。
在這裡，無論前端和後端都會面臨同樣的問題：如何解耦這些複雜的業務邏輯。
後端工程師是幸運的，Spring這個元老級的框架已經為他們鋪設好了大量的基礎設施，像是依賴注入、面向切片程式設計以及大量優質註解和上層封裝介面。同時，社群也總結出瞭如下圖的業務邏輯分層：
有了基礎設施，再結合社群的經驗，後端工程師能很容易的拆解業務邏輯，並複雜的業務邏輯從Controller拆分到Service層，Service再通過DAO層進行資料庫讀寫。
但作為前端工程師，如果我遇到這種情況，就會比較迷茫。
類比學習
其實上述的分層是能為前端所用的，我們只需要根據前端的實際情況做一些適應性修改即可。
先思考一個問題：為什麼要有Service層
在MVC中的Controller層，伺服器需要接收來自Client的請求，經過一些處理，最後返回一個合理的響應。在這個過程中，不可避免地需要與資料庫進行互動，如果把請求的讀取、資料庫的讀寫、響應的拼裝都放在Controller裡的話，程式碼必然會變得難以維護，所以才有了Service層，這就是後端需要解決的痛點。
再思考一個問題：前端有沒有上述痛點
後端的過程是這樣的：接受請求、資料庫讀寫、返回響應。
前端的過程是這樣的：組織引數、發起請求、處理響應。
如果我們把這三個過程都寫在VM裡（通常是我們的元件），程式碼肯定會變的難以維護，單元測試更是想都別想。
最後思考一個問題： 怎麼讓Service層為我所用
Service的正確使用姿勢應該是跟Spring這樣的有控制反轉功能的框架結合，通過依賴注入的形式得到Service例項，然後直接使用這個例項。
Angular官方文件已經給出基於依賴注入的Service使用方式了，直接去看即可：www.angular.cn/guide/archi…
然而作為React和Vue的使用者，該怎麼用呢？
條條大路通羅馬，怎麼用都可以。舉個例子，我就單獨新建一個dashboardSrv.js檔案，然後把所有涉及到網路請求的複雜業務邏輯都放進去，然後在元件裡import進來，完全沒問題。
一些很好的學習物件
重要的是意識
要對前端工程化有一個全域性的意識，知道自己寫的程式碼位於架構分層的什麼位置，並且有意識去汲取其他競品、其他領域的經驗，為自己所用。
期待前端能有一個自己的Spring框架。