文/文靜
編輯/麥壁瑜
前言
在軟體體系架構設計中，有一種最經典的三層結構，即：表現層、業務邏輯層和資料通路層。
- 表現層（UIL）：展現給使用者的界面，即使用者在使用系統時他的所見所得。
- 業務邏輯層（BLL)：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。
- 資料通路層（DAL)：針對資料的增添、删除、修改、查找等。
在明道雲的應用搭建過程中，雖然不要求開發者去嚴格定義三層結構，但在很多産品設計上仍然可以體會到分層的理念。例如：在顯示記錄資訊的“前端表單”上，我們可以通過資料的增删改或是自定義按鈕來調用一個“背景工作流”。工作流中可以進行各種複雜邏輯的處理，并對相應的“底層工作表”進行資料操作。
這樣的設計思路易于使用者了解，不管是習慣代碼開發的程式員還是新手小白，隻要稍加熟悉各層基本功能元件，就能很容易設計各種複雜和個性化的業務應用。
三層結構的設計擴充性強，可以很好地降低各層之間的耦合度，有利于标準化和邏輯的複用。但是它也會帶來一些問題，如：
- 一定程度上降低了系統性能。例如：明道雲對資料的批量複雜處理主要依靠大量的工作流（包含子流程），當複雜的工作流嵌套較多的時候，維護起來會有難度。
- 前後端關聯處理，牽一發而動全身。例如：為了在前端大屏上顯示全面的資料可視化效果，要組合運用一系列字段、資料關聯、工作流才可以實作。
今天就探讨一種特殊的方法，打破“前後端”的藩籬，讓我們能在工作表前端建立一個自定義的高速緩存。在一些特殊場景下可以提升資料性能，同時讓應用設計更加簡潔。
自定義資料結構，把文本控件變成高速緩存
從 7.3 版本開始，明道雲産品在原有的函數預設值基礎上又往前推動了一步，開始支援“自定義函數”。這樣一個小疊代，卻能為我們在前後端開發上開啟一扇大門，讓我們可以嘗試用新的方式來解決前後端複雜資料互動的問題。
這個思路的核心是将工作表文本控件作為前端資料存儲容器，通過自定義函數進行讀取和前端邏輯處理。其中，資料本身還是來源于正常的工作表，但是可以通過工作流讀取一個或多個表的資料，并重構出一個獨立的前端資料源。這個資料可以直接存儲在工作表中，作為前端自定義函數可通路的“資料緩存”。
示例效果
下面，我先用一個簡單示例來示範這個操作過程。示例背景：在一個工作表中輸入“員工工号”，系統就可以自動帶出該員工的姓名、崗位、入職日期。
實作這個效果的正常方式步驟為：
- 在查詢表中建立一個單條的人員崗位關聯控件；
- 為這個關聯控件設定一個查詢他表的預設值，條件為目前輸入的工号
- 通過他表字段或者文本控件預設值把該關聯的相關字段引入到目前記錄。
可以看出，這個過程需要多個元件的聯合使用，且必須要求查詢表單動态建立和人員表的關聯。前台執行效率較慢，關聯字段也做不到實時重新整理顯示。而通過今天介紹的自定義函數模式就可以完美解決這些問題，下面看一下效果。
步驟講解
1.首先，在查詢表單中設定一個“資料緩存”容器，用普通的文本控件即可；可保持隐藏狀态。
2.根據實際業務對資料的需求，用工作流在背景生成特定JSON格式的資料源，并儲存在上面的“資料緩存”容器中。這裡的資料源格式非常靈活，可以支援一些相對複雜的業務（參考：運用代碼塊将工作表資料轉為數組 https://bbs.mingdao.net/topic/137）。
3.在目标控件中設定自定義函數。通過加載對應的“緩存資料”，再結合自定義JS代碼，即可實作自定義的判斷和計算邏輯。如本示例中，根據輸入的工号檢索數組對象，并顯示其中的字段值（可以根據輸入實時重新整理資料）。
更多應用場景
除了輸入工号自動顯示員工資訊以外，這個操作方法還可以應用在各種場景中：
1.考試測評中實作試卷題目一次性加載
線上考試、測評場景中，試卷題目一次性加載；題目的切換無需背景工作流，純前端重新整理更加順暢。
2.訂單明細按條件動态彙總統計
如果按标準的方式，我們隻能先預置幾個帶有篩選條件的彙總控件，再用公式字段将所有彙總值加起來。而用這種自定義函數就可以實作按條件動态彙總。控件的使用數量也更少，而且彙總數量可以輕松突破1000條的限制。
資料統計實作方式如下：
3.較為複雜的判斷
在預定會議室的場景中，要按照自定義的會議起止時間，自動判斷并顯示可用會議室清單。
總結
今天探讨的這種方式讓我們在标準産品體系之外，可以建構出自己獨立的前端資料緩存，實作基于自定義函數的一些特殊資料處理邏輯。當然，這種方式也有一定的局限和要求：
1.隻在人工執行資料操作時觸發
自定義函數是一個純“前端”功能，隻能在人工進行資料操作的時候才會觸發。如果其他事件會影響資料的變更還是要基于标準的“背景”工作流來處理。
2.本身無法和底層工作表資料實時同步
雖然對大量資料的彙總計算可以超過1000條，但是由于此資料源隻是底層工作表的一個副本，本身無法和底層工作表資料進行實時同步，除非通過工作流頻繁同步。是以這種方式适合處理相對靜态的資料。如上面的示例，一套考題生成後一般就不會再變化了，一個訂單的明細在進入一定階段後，如審批通過，也不會再做變更。
看完這篇文章的你，不妨也嘗試用這種方式整合前後端資料，做一些有趣的探索。