需要指針來編寫一個可擴展的報表引擎

Question

由於當前報表產品的侷限性（SSRS，Crystal Reports）以及我的用戶主要是熟悉Excel的財務/業務人員，我正在考慮使用Excel編寫我自己的報表引擎組件如SpreadsheetGear或Aspose.Cells，並將其集成到我們的WinForms應用程序中。

這兩個庫都提供一個電子表格查看器WinForms組件，因此生成的電子表格報告將在保存其參數後以表單的形式顯示給用戶，然後他可以保存它。

我已經在一個單獨的winforms項目上完成了它，它顯然很容易。只需將參數控件放在表單中，連接到數據庫，生成電子表格並完成。

但是，爲每個報告執行此操作顯然需要重複「樣板」代碼和表單設計，並降低應用程序的可維護性和可升級性。因此，我正在考慮將報告編寫爲插件（DLL），它只提供生成報告的代碼/邏輯，並將最終工作表對象返回給調用者（「Report Preview」窗體） 。

一番考慮之後，我認爲主叫和外接之間的職責是如下共享：

報告DLL /插件將提供主叫方（主UI）的列表用戶需要爲此報告傳遞的參數，以及其名稱，可能的值（例如，組合框的列表）。

然後它將由主UI在表單上創建它們。控件類型將根據參數的數據類型推斷出來（一個字符串將是一個TextBox等）。

主UI會將填充參數傳遞給報告生成方法，以及一些應用程序特定設置（連接字符串，應用程序的用戶名）。

報表DLL將生成報表並返回到主UI生成的工作表/報表對象並將其顯示在預覽控件上。

要做到這一點從技術上來說，我認爲我需要創建一個接口，用於我的報告的DLL，並實現像

List<ReportParameter> GetReportsParameters() 
Report GenerateReport() 

從主UI方法，我將訪問他們，叫他們通過反思。

這聽起來像一個很好的策略，它是否爲未來的可擴展性留下了適當的空間？ 我希望在模塊化之間取得良好平衡，同時不會因爲我的插件體系結構對未來過於靜態而受到靈活性的限制。

如果您在過去取得類似的成績，您是否可以提供一些有用的提示以確保這一點並共享？

謝謝。我正在用C＃，.Net 4.0和WinForms開發數據庫後端是SQL Server 2005）。

Answer 1

看看Templater。它可能已經做了你想要的大部分東西。

在Github上有真實示例。

Disclamer：我是圖書館的作者。