要回答這個問題，首先要明確啥程度算“零編碼”？
以 Excel 為例，如果把寫 Excel 公式（包括復雜一些的）看做零編碼；而把寫 Excel VBA 看做編碼的話，

報表開發(fā)是可以零編碼的！

但是，這有個前提：在數(shù)據(jù)（集）準備好的情況下才可以零編碼！

為什么這么說？
我們知道報表開發(fā)主要分兩個階段：
第一階段是為報表準備數(shù)據(jù)，也就是把原始數(shù)據(jù)通過 SQL/ 存儲過程加工成數(shù)據(jù)集；
第二階段是使用已準備的數(shù)據(jù)編寫表達式做報表呈現(xiàn)。在報表工具提供的 IDE 里可視化地畫出報表樣式，然后再填入一些把數(shù)據(jù)和單元格綁定的表達式就可以完成報表呈現(xiàn)了，雖然表達式可能比較復雜，但相對硬編碼要簡單得多（Excel 公式和 VBA 的關系）。所以說這個階段是能做到“零編碼”的。

那報表數(shù)據(jù)準備怎么辦？
很遺憾，這個階段沒法零編碼，一直以來只能硬編碼，想想我們報表里寫的嵌套 SQL、存儲過程、JAVA 程序就知道了。為什么報表工具發(fā)展這么多年報表呈現(xiàn)已經(jīng)完全工具化而報表數(shù)據(jù)準備的手段還這樣原始呢？因為這個階段太復雜了，不僅涉及計算邏輯的算法實現(xiàn)，還涉及報表性能（要知道大部分報表性能問題都是數(shù)據(jù)準備階段引起的）。

那報表數(shù)據(jù)準備是不是沒辦法了呢？
雖然不能做到零編碼，但可以朝著簡單化的方向努力，將數(shù)據(jù)準備階段也工具化，這樣可以使用工具提供的便利來簡化報表數(shù)據(jù)準備階段的工作，從而進一步簡化報表的開發(fā)。

那怎么實現(xiàn)報表數(shù)據(jù)準備工具化？
要實現(xiàn)這個目標并不容易，像上面提到要考慮的內(nèi)容有點多，大體來說數(shù)據(jù)準備工具至少要滿足這幾方面：1. 具備完備的計算能力
說的有點拗口，掰開了其實在說既然在工具里做數(shù)據(jù)計算，那得讓我什么都能算吧，不能原來 SQL/JAVA 寫的放到這里就不行了，該有的計算方法和類庫都應該有，最好用起來還比較簡單（比原來硬編碼難就沒意義了），專業(yè)的說法叫：計算體系是完備的；2. 支持熱切換
這點是相對 JAVA 來說的，通過數(shù)據(jù)準備工具生成的算法應該是解釋執(zhí)行的，不能每次改完報表還要重啟應用，即時修改即時生效；3. 具備多源混算能力
通過數(shù)據(jù)準備工具可以同時連接多種數(shù)據(jù)源（RDBMS、NoSQL、TXT、Excel、Hadoop、HTTP、ES、Kafka 等等）進行計算，混合計算，這個數(shù)據(jù)源讀個表、那個數(shù)據(jù)源加載個文件，兩部分數(shù)據(jù)可以 join 到一起混算?，F(xiàn)在我們的數(shù)據(jù)源太多了，報表常常會跨數(shù)據(jù)源取數(shù)，支持了異構源混算以后，原來還要考慮諸如數(shù)據(jù)是不是先入到一個庫里的事情就不用管了，那叫一個清爽；4. 高性能
直接簡化數(shù)據(jù)準備的工作還不夠，實現(xiàn)再簡單跑不快也不行。所以，還要高性能，至少不能比原來跑的慢吧，大家都是講道理的人；

以上是我認為數(shù)據(jù)準備工具必備的能力，其他還有一些能力不是特別重要，但如果有最好了。包括：
* 有沒有易用的編輯調(diào)試環(huán)境，可以很方便地調(diào)試算法；
* 為了更快能不能并行計算
* 有沒有標準接口可以讓其他程序或工具調(diào)用
等等，實際要用的時候照著這些特點去找就行了，有益無害。

說了這么多，總結(jié)來說，“零編碼制作報表”的確更像一句口號，沒法真正做到，但可以不斷努力接近這個目標，求其上得其中嘛。

參考資料：
【數(shù)據(jù)蔣堂】第 43 期：報表開發(fā)的現(xiàn)狀
報表提效資料匯總（體系結(jié)構和性能優(yōu)化）

總結(jié)

以上是生活随笔為你收集整理的vb.net怎么调用fastreport报表_零编码制作报表可能吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。