我們在上一期已經解釋了報表應用結構中數據計算層的必要性，以及可以使用報表工具自定義數據源接口來實現計算層。在計算層中要完成一些復雜的計算邏輯，因此要有可編程的能力，而基于自定義接口可以采用報表工具的宿主語言(即用于開發報表工具的程序設計語言)進行開發，在功能方面沒有問題，不過，實際應用中卻仍有不少缺陷。更好的方式是實現一個顯式的數據計算層，在其中提供可解釋執行的腳本功能，把數據源計算獨立出來。

我們從四個方面來分析后者的優勢。

代碼編寫

報表工具的宿主語言一般是Java、C#等高級語言，這類語言針對結構化數據集的支持很有限，雖然都能做，但卻非常繁瑣，簡單做個求和運算都需要寫數行代碼的循環來實現。而報表數據源處理則大量涉及批量數據運算，采用高級語言開發時會導致動輒數百行的冗長代碼，編寫和調試都很困難。

專門為數據計算設計的腳本則能夠提供豐富的結構化數據集運算功能，可以很方便地實現批量數據計算。代碼更短不僅是工作量更少、調試方便，而且還有利于整體了解和把握算法。如果語言設計得好，大多數報表的數據源準備算法都可以在一屏內實現，整個算法過程一目了然。

應用耦合

報表的呈現式樣是由報表工具繪制的模板來控制，報表模板一般以文件形式存放在文件系統中。如果數據準備采用自定義數據源實現，這部分代碼將作為應用程序的一部分被一起編譯和打包。呈現模板和數據集算法作為同一個報表的兩個關鍵要素必須合理配合才能正常工作，但物理上卻會分存于兩處，甚至可能是不同人員開發的，這給修改維護報表帶來麻煩，需要刻意去保持兩處的一致性。

獨立計算層的計算腳本和報表模板一樣，都是解釋執行的，腳本也可以文件形式與和報表模板放在一起，報表維護時很容易保證這兩部分一致，這方面不存在應用耦合問題。

熱切換

報表的數據集算法如果使用自定義數據源實現，那就會成為應用程序的一部分，發生修改時就需要和整個應用程序一起重新編譯打包，并且在大多數情況時需要將應用停機后再重啟。而報表是個業務穩定性相對較差的功能，經常會增加和修改，這樣就會導致應用程序頻繁重啟。雖然Java等開發機制也支持熱加載，但使用復雜，大多數應用程序員難以掌握。而且一旦加載后的程序就不會被清除，即使不再有用也會一直占據內存，熱加載技術并不很合適應用于報表數據源。

類似地，熱切換對于使用獨立計算層的腳本也不再是問題，有報表修改只要修改呈現模板和相應的計算腳本。因為腳本是解釋執行的，應用程序本身并不需要改變，也就沒有必要停機重啟。被修改的報表在訪問時臨時計算即可。

開發人員

使用Java等高級語言實現報表數據集準備時，需要在代碼中引用數據庫連接、基礎類庫等各種環境信息，還要了解和遵循整個應用程序的代碼規范以保持協調，這常常是項目組中的專業程序員才能掌握的技能。而開發報表數據集只要了解數據結構和運算邏輯，其實用戶方有不少技術人員都擁有這個能力，但苦于難以理解開發環境而很難自由實現新的報表。

有獨立計算層時，報表開發需要的各種環境信息可以事先在應用程序中配置好，使用腳本編程時也不必關心整個應用的代碼規范，報表開發人員只要關心數據結構和運算邏輯，可以用于開發報表的人員更多，以適應報表頻繁修改的業務特性。

【本文為51CTO專欄機構“數據蔣堂”的原創稿件，轉載請聯系原作者】