【发布时间】:2025-11-23 04:30:02
【问题描述】:
由于当前报告产品的局限性(SSRS、Crystal Reports)以及我的用户主要是熟悉 Excel 的财务/商务人士,我正在考虑使用像 SpreadsheetGear 或 Aspose.Cells 这样的 Excel 组件编写自己的报告引擎,并将其集成到我们的 WinForms 应用程序中。
两个库都提供了电子表格查看器 WinForms 组件,因此生成的电子表格报告将在保存其参数后以表单的形式显示给用户,然后他可以保存它。
我已经在一个单独的 winforms 项目中完成了这项工作,这显然很容易。只需将参数控件,在表单中,连接到数据库,生成电子表格即可。
但是,对每个报告都这样做显然会涉及大量重复“样板”代码和表单设计,并降低应用程序的可维护性和可升级性。
因此,我正在考虑将报告编写为插件 (DLL),它只会提供生成报告的代码/逻辑,并将最终的工作表对象返回给调用者(“报告预览”表单)。
经过一番思考,我认为调用者和加载项之间的责任如下:
报告 DLL/加载项将为调用者(主 UI)提供用户需要为此报告传递的参数列表,以及其名称、可能的值(组合框列表,例如示例)。
然后由主 UI 在表单上创建它们。控件类型将根据参数的数据类型推断(字符串可以是 TextBox 等)。
主 UI 会将填充的参数以及一些应用程序特定的设置(连接字符串、应用程序的用户名)传递给报表 DLL。
然后报告 DLL 将生成报告并将生成的工作表/报告对象返回到主 UI,并将其显示在预览控件上。
为了在技术上实现这一点,我认为我需要为我的报告 DLL 创建一个接口,并实现类似的方法
List<ReportParameter> GetReportsParameters()
Report GenerateReport()
从主 UI 中,我将访问它们并通过反射调用它们。
这听起来是不是一个不错的策略,是否为未来的可扩展性留下了不错的空间? 我希望在模块化之间取得良好的平衡,同时不会因为我的加载项架构对于未来过于静态而受到限制。
如果您过去取得了类似的成就,您能否提供一些有用的提示来确保这一点并分享?
谢谢。
(我正在使用 C#、.Net 4.0 和 WinForms 进行开发。数据库后端是 SQL Server 2005)。
【问题讨论】:
-
另外,像 MEF(Microsoft 可扩展性框架)或 MAF(Microsoft 插件框架)这样的 MS 技术可以提供帮助吗?还是他们似乎为此矫枉过正?
标签: .net reflection reporting extensibility