前端實現(xiàn)業(yè)務，后端處理數(shù)據(jù)计维。在現(xiàn)代框架實現(xiàn)前后端分離后，前后端的交互基本分為2種： 數(shù)據(jù)讀取和數(shù)據(jù)寫入撕予。而前端由于業(yè)務的復雜性鲫惶，也存在開發(fā)效率低，組件話實施困難的難點实抡。本篇就是探討我目前的解決方案欠母。
數(shù)據(jù)讀取
MVC的開發(fā)模式： 前后端商量好數(shù)據(jù)結(jié)構(gòu) -> 后端完成API開發(fā) -> 前端根據(jù)API的參數(shù)實現(xiàn)業(yè)務邏輯。
這樣的問題在于：
- 可能會重復開發(fā)很多類似的接口
- 由于不同人參與項目吆寨，同一個參數(shù)可能會有不同命名方式赏淌，取數(shù)方法也可能重復
- 溝通成本高
解決方式：
- 業(yè)務驅(qū)動，由更靠近業(yè)務的前端來決定需要什么數(shù)據(jù)啄清，在mutation中就定義好需要那些字段六水，向后臺索取
- 后臺準備好所有的數(shù)據(jù)的獲取方式，根據(jù)前端的需求給出
- 后臺的數(shù)據(jù)盡量扁平辣卒，層級控制在2級之內(nèi)
如圖所示掷贾，前端展示需要Person.name等幾個信息，于是發(fā)出請求向后端索取荣茫。
在后端的庫里已經(jīng)有一個Person相關(guān)所有參數(shù)的getter想帅，只要根據(jù)前端需要的數(shù)據(jù)提供即可。
后端的getter中可以看到啡莉，所有參數(shù)來自與幾個不同的庫港准，有Person這個主要的庫，也有PersonJob咧欣，PersonProfile等從屬與Person的庫浅缸。我們把多層級的庫在getter層合并為同一層級，這樣對于前段來說更加清晰该押。同時疗杉，字段名稱也可適當更改，來幫助前端更利于理解蚕礼。
如此一來烟具，在開發(fā)時，新的順序為：
- 前端通過getter選取需要的參數(shù)奠蹬，如果參數(shù)不存在朝聋，讓后端新增此參數(shù)
- 前端并獲取所需數(shù)據(jù)，實現(xiàn)業(yè)務邏輯
前后端的開發(fā)就清晰了很多囤躁，代碼復用率大大提高冀痕，效率明顯提升
數(shù)據(jù)寫入
寫入的操作更為復雜荔睹，可能create，update或delete言蛇，可能是表單觸發(fā)或點擊按鈕觸發(fā)僻他，可能是單一model修改，也可能牽連到多個model腊尚。所以吨拗，寫入操作即要讓代碼有序，又要能夠很靈活的開發(fā)婿斥，避免業(yè)務復雜后大量的if-else
解決方式
- 通過setter劝篷，定義常規(guī)的model修改邏輯，如修改personJob時一定會修改personJobStatus
- 通過插件民宿，可在API調(diào)用前后娇妓，或某個model修改前后，或某個model參數(shù)修改前后活鹰，觸發(fā)插件模塊化的代碼哈恰，來達到解耦的目的。如輸入的是rawData华望，在修改Person.salary前蕊蝗，插入績效規(guī)則的代碼塊仅乓，把rawData經(jīng)過績效規(guī)則的計算后轉(zhuǎn)化為salary赖舟，在通過setter走常規(guī)的流程，計入PersonJob.salary中夸楣。由于績效規(guī)則的多變行宾抓，通過插件配置的方式把不同的項目的績效邏輯分離，達到解耦的效果豫喧。
前端組件化
可配置化石洗，理想的情況是有一個后臺，前端的標準組件紧显，如form讲衫，list，card等都由configureable封裝孵班，有一個前端配置UI可以看到那個頁面放置了哪些組件涉兽，有哪些配置項，然后由配置UI配置好后對改組件進行靈活的風格化篙程。
可配置項包含組件參數(shù)枷畏，組件API調(diào)用，組件位置等
如此一來虱饿，前端開發(fā)就類似于搭積木拥诡，把幾個組件一搭触趴，一些可能會經(jīng)常改動或多變的業(yè)務需求放置在后臺配置，一個頁面就出來了渴肉。
配置UI
最最重要的是冗懦，無論是前端配置，后端插件配置仇祭，還是后端可提供的參數(shù)批狐，都需要一個好用方便的配置UI界面來理解和操作。這樣才能化解因為框架所帶來的額外的學習成本和理解成本前塔。
