前端實(shí)現(xiàn)業(yè)務(wù)，后端處理數(shù)據(jù)。在現(xiàn)代框架實(shí)現(xiàn)前后端分離后，前后端的交互基本分為2種： 數(shù)據(jù)讀取和數(shù)據(jù)寫(xiě)入。而前端由于業(yè)務(wù)的復(fù)雜性，也存在開(kāi)發(fā)效率低，組件話實(shí)施困難的難點(diǎn)。本篇就是探討我目前的解決方案。
數(shù)據(jù)讀取
MVC的開(kāi)發(fā)模式： 前后端商量好數(shù)據(jù)結(jié)構(gòu) -> 后端完成API開(kāi)發(fā) -> 前端根據(jù)API的參數(shù)實(shí)現(xiàn)業(yè)務(wù)邏輯。
這樣的問(wèn)題在于：
- 可能會(huì)重復(fù)開(kāi)發(fā)很多類似的接口
- 由于不同人參與項(xiàng)目，同一個(gè)參數(shù)可能會(huì)有不同命名方式，取數(shù)方法也可能重復(fù)
- 溝通成本高
解決方式：
- 業(yè)務(wù)驅(qū)動(dòng)，由更靠近業(yè)務(wù)的前端來(lái)決定需要什么數(shù)據(jù)，在mutation中就定義好需要那些字段，向后臺(tái)索取
- 后臺(tái)準(zhǔn)備好所有的數(shù)據(jù)的獲取方式，根據(jù)前端的需求給出
- 后臺(tái)的數(shù)據(jù)盡量扁平，層級(jí)控制在2級(jí)之內(nèi)
如圖所示，前端展示需要Person.name等幾個(gè)信息，于是發(fā)出請(qǐng)求向后端索取。
在后端的庫(kù)里已經(jīng)有一個(gè)Person相關(guān)所有參數(shù)的getter，只要根據(jù)前端需要的數(shù)據(jù)提供即可。
后端的getter中可以看到，所有參數(shù)來(lái)自與幾個(gè)不同的庫(kù)，有Person這個(gè)主要的庫(kù)，也有PersonJob，PersonProfile等從屬與Person的庫(kù)。我們把多層級(jí)的庫(kù)在getter層合并為同一層級(jí)，這樣對(duì)于前段來(lái)說(shuō)更加清晰。同時(shí)，字段名稱也可適當(dāng)更改，來(lái)幫助前端更利于理解。
如此一來(lái)，在開(kāi)發(fā)時(shí)，新的順序?yàn)椋?/p>
- 前端通過(guò)getter選取需要的參數(shù)，如果參數(shù)不存在，讓后端新增此參數(shù)
- 前端并獲取所需數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)邏輯
前后端的開(kāi)發(fā)就清晰了很多，代碼復(fù)用率大大提高，效率明顯提升
數(shù)據(jù)寫(xiě)入
寫(xiě)入的操作更為復(fù)雜，可能create，update或delete，可能是表單觸發(fā)或點(diǎn)擊按鈕觸發(fā)，可能是單一model修改，也可能牽連到多個(gè)model。所以，寫(xiě)入操作即要讓代碼有序，又要能夠很靈活的開(kāi)發(fā)，避免業(yè)務(wù)復(fù)雜后大量的if-else
解決方式
- 通過(guò)setter，定義常規(guī)的model修改邏輯，如修改personJob時(shí)一定會(huì)修改personJobStatus
- 通過(guò)插件，可在API調(diào)用前后，或某個(gè)model修改前后，或某個(gè)model參數(shù)修改前后，觸發(fā)插件模塊化的代碼，來(lái)達(dá)到解耦的目的。如輸入的是rawData，在修改Person.salary前，插入績(jī)效規(guī)則的代碼塊，把rawData經(jīng)過(guò)績(jī)效規(guī)則的計(jì)算后轉(zhuǎn)化為salary，在通過(guò)setter走常規(guī)的流程，計(jì)入PersonJob.salary中。由于績(jī)效規(guī)則的多變行，通過(guò)插件配置的方式把不同的項(xiàng)目的績(jī)效邏輯分離，達(dá)到解耦的效果。
前端組件化
可配置化，理想的情況是有一個(gè)后臺(tái)，前端的標(biāo)準(zhǔn)組件，如form，list，card等都由configureable封裝，有一個(gè)前端配置UI可以看到那個(gè)頁(yè)面放置了哪些組件，有哪些配置項(xiàng)，然后由配置UI配置好后對(duì)改組件進(jìn)行靈活的風(fēng)格化。
可配置項(xiàng)包含組件參數(shù)，組件API調(diào)用，組件位置等
如此一來(lái)，前端開(kāi)發(fā)就類似于搭積木，把幾個(gè)組件一搭，一些可能會(huì)經(jīng)常改動(dòng)或多變的業(yè)務(wù)需求放置在后臺(tái)配置，一個(gè)頁(yè)面就出來(lái)了。
配置UI
最最重要的是，無(wú)論是前端配置，后端插件配置，還是后端可提供的參數(shù)，都需要一個(gè)好用方便的配置UI界面來(lái)理解和操作。這樣才能化解因?yàn)榭蚣芩鶐?lái)的額外的學(xué)習(xí)成本和理解成本。
