对当前报表产品的局限性(SSRS, Crystal Reports)感到沮丧，并且我的用户主要是熟悉Excel的财务/商务人士，我正在考虑使用SpreadsheetGear或Aspose等Excel组件编写自己的报表引擎。单元格，并将其集成到我们的WinForms应用程序中。
两个库都提供了一个电子表格查看器WinForms组件，因此生成的电子表格报告将在保存其参数后以表单的形式显示给用户，然后他可以保存它。
我在一个单独的winforms项目上做过这个，显然很容易。只要把参数控件放在表单中，连接到数据库，生成电子表格，就完成了。
然而，对每个报告都这样做显然会涉及到大量的"样板"代码和表单设计的重复，并降低应用程序的可维护性和可升级性。
因此，我正在考虑将报告作为插件(DLL)编写，这只会提供代码/逻辑来生成报告，并将最终的工作表对象返回给调用者("报告预览"表单)。
经过一番思考，我认为调用者和外接程序之间的责任应该如下分配:
报告DLL/外接程序将向调用者(主UI)提供用户需要传递给该报告的参数列表，以及它的名称、可能的值(例如，一个组合框的列表)。
然后由主UI在表单上创建这些属性。控件类型将根据参数的数据类型推断出来(字符串可能是TextBox等)。
主UI将把填好的参数传递给报表生成方法，以及一些应用程序特定的设置(连接字符串、应用程序的用户名)。
报告DLL将生成报告，并将生成的工作表/报告对象返回给主UI，并将其显示在预览控件上。
要在技术上实现这一点，我认为我需要为我的报表dll创建一个接口，并实现像
这样的方法List<ReportParameter> GetReportsParameters()
Report GenerateReport()
从主UI，我将访问它们并通过反射调用它们。
这听起来像一个好策略吗?它是否为未来的可扩展性留下了体面的空间?我希望在模块化和灵活性之间达到一个很好的平衡，而不是因为我的外接程序架构在未来过于静态而受到限制。
你是否有一些有用的技巧来确保这一点，并分享你过去取得类似成就的经验?
谢谢。
(我正在使用c#、。net 4.0和WinForms进行开发。数据库后端为SQL Server 2005)
看看Templater。它可能已经完成了你想要的大部分功能。
Github上有真实世界的例子。
声明:我是这个库的作者。