前言
公司的這個項目從去年底啟動、至今經歷winform版本與當前的VUE兩個版本，前后經歷不足3個月的時間。從純技術角度來看，推進速度都很優異。究其原因，大抵我們都是喜歡“偷懶”的程序員，把能封裝、能公用的代碼盡可能的整合起來。多寫一行代碼都覺得遭罪。一路懶下來，倒也有所收獲。接下來進行一些總結，不求大而全，只求小而精，不積小流無以成江海。
數據轉換之道
今天我要分享的是雲倉VUE項目中，快速簡單地實現接口返回的列表數據自動在前端完成鍵值數據轉換方案。接下來先貼一張圖，說明我們的解決方案，如下：
關於數據庫中業務單據上保存的外鍵字段如何方便地在前端展示成用戶可讀信息，這個問題我相信每個開發人員都會遇到。舉例說明：庫存表(Stock)包含材質id，在UI層如何將材質id轉換成名稱？按照一般的思路來講，我們只需要將庫存表與材質表關聯，再將材質名稱與庫存主數據組裝成model對象返回給前端table綁定即可。這么做有他的好處，直觀、性能好，view層只管呈現接口數據就可以了。不過，缺點卻也很明顯，羅列如下：
- 數據訪問層要寫表關聯查詢的sql語句；
- 接收實體要定義UI需要展示的擴展字段；
- 代碼復用性降低，需要針對不同的UI場景，編寫相對應的后端取數邏輯；
- 將轉換工作交給每一個功能單獨處理，面臨着研發對表結構不明確或者手誤等原因引發bug的高風險。
- 費事費力，開發需要對相關聯表結構有清晰的認識；
- 代碼可維護性低、交接難度大；
- 項目擴展性差，極可能面對基礎數據一處調整，業務單據處處調整的尷尬場面；
前面講過，我們是一個會“偷懶”的團隊，這種事情想想都可怕，必然要扼殺之於搖籃。也因此，便有了我們的數據轉換之道。
我們的解決方案如上圖所示，核心在於三點：緩存、集中配置、轉換器。具體實現過程簡要描述如下：
- 用戶登錄完成后，獲取DB基礎數據，存儲在前端全局緩存中(B)；
- 后台開發websocket消息服務，VUE項目啟動后進行連接。監聽到基礎數據發生改變后，后台通知所有在線客戶端拉取最新數據，更新緩存(A)；
- VUE項目中設有元數據集中配置模塊，與DB實體建議一一映射關系，配置數據轉換對應關系、靠齊方式、格式化方式、精度說明等信息，為轉換器提供元數據(D)。
- 用戶進入具體頁面，后台接口返回原始業務數據，不需做表關聯，直接返回單表數據。此時的材質id還是個整數，並不是想要看到的名稱。之后，將遠程請求回來數據綁定給我們開發的table組件，組件調用系統轉換器進行內容轉換，得到可讀數據呈現給用戶(C)；
基於此解決方案，我們接下來的開發姿勢就變成了這樣。請往下看。
“嗨，伙計！趕緊開發一個庫存明細界面~”
“沒問題，稍等~”
一、 先在元數據中配置一下實體信息(集中配置，一次即可，后續DB不動，就無需修改)；
二、添加庫存明細組件，繪制table表格；
三、發起http請求，獲取數據源進行綁定；
四、效果展示
寫在最后
當集中配置中心的元數據配置完成后，我們開發表格時就只需要申明table組件需要加載的實體對象，以及各列對應的字段名即可。不必考慮表關聯、model的定義、數據管理等等這些繁瑣的事情。一切都以傻瓜式開發為目標。而數據轉換模塊的集中化處理，又為系統帶來的高可維護、可擴展、系統穩定、代碼可讀等諸多優點。
基於此數據轉換模型，除了table組件，我們還相應完成了form表單、search搜索區域、權限控制等模塊化組件。讓vue項目的高速推進成為可能。
一旦實現完善的集中化配置，隨着時間的推移，系統的運轉會愈加良善。研發省去了大量雞零狗碎的無關於業務的邏輯處理，專注於快速高效的解決業務問題本身。反過來，又擠出了時間繼續做框架上的優化提升，繼續為“偷懶”做准備。