MVVM分層下的前端工程化開發

時間 2019-11-06

標籤 mvvm 分層前端工程開發简体版

原文原文鏈接

在MVVM分層之下

MVVM把一個系統拆分紅視圖層、視圖數據層、數據訪問層：前端

對於基於MVVM架構的庫，View層就是DOM，ViewModel層就是組件，Model層就是state或props。此外，若是咱們使用狀態管理庫，那麼Model層就是store。

但咱們要搞清楚一點，MVVM是MVVM庫設計時所遵循的原則，而不是咱們寫代碼時應該遵循的。咱們只是在MVVM分層下，分別在Model、VM、View這三個部分寫本身的業務代碼。git

所以，咱們還須要找出一系列範式，在基於MVVM的大流程下，指導咱們寫出分層合理、可拓展的業務代碼。github

庫與框架

庫 + 範式 = 框架數據庫

遺憾的是，因爲缺乏官方給出的一系列範式，咱們經常使用的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實例，而後直接使用這個實例。