需要架构指导？

Question

我们即将为我们的报告团队自动化流程数量。 （报表有日报、周报、月报等）

大多数情况下，这个过程就像从 oracle 中提取一些数据然后填充它们 特别是 excel 模板文件。

每个报告及其模板彼此不同。 除了excel文件操作，这些背后几乎没有任何业务逻辑。

客户想要一个集成工具，所有自动化流程都被放置为 菜单/子菜单。

目前大约有 30 个流程等待自动化。 我们预计下一季度会有更多新报告。

在架构方面，我几乎没有任何实际经验。 我已经在维护两个或三个系统（它们已经超过 4 年了。） 对于这个著名的客户。上述工具很有可能再维持 3 年。

根据我过去的经验，我曾经历过向僵化和未记录的代码库实施更改请求的痛苦，导致系统崩溃，最终导致我自己崩溃。

所以我主要和最关心的是可维护性。

当我搜索这些时，我遇到了这个链接， Smart Clients Using CAB and SCSF 上面的链接适合我的要求吗？

我还应该将每个自动化流程以单独的形式放在一个项目下吗？ 或将它们放在单个解决方案下的单独项目中..

如果遗漏了任何其他重要信息，请纠正我。

谢谢。

Answer 1

我们多年前建立了一个类似的系统。该系统由一个主进程和一系列实现插件架构的 Excel 报告生成器组成。每个报告都有自己的报告生成器，并且可以按自己的时间表生成，这与quartz 和quartz.net 处理调度的方式非常相似（但这是在它们创建之前很多年）。插件架构是系统的关键，因为可以动态创建和放入新的报告生成器。

主要过程负责启动/监控生成器，侦听由生成器触发的事件，以及分发所有报告。分发主要包括到文件服务器的 FTP，在该服务器上可以从网站查看和保存报告。但我们也确实有一些报告通过电子邮件发送到分发列表。

存储所有报告数据的主数据库还包含所有系统元数据，这些元数据通知主进程和生成器他们要执行的工作的细节。

在我们的系统中，所有报告都是按顺序运行的，主要是由于当时的 Excel 限制。假设 Excel 现在能够自行运行，那么没有理由不能将新系统设计为并行运行。

Answer 2

为什么不用适当的报告解决方案替换各种 Excel 模板？使用体面的报告产品有以下好处：

• 每个人都可以访问同一份报告
• 您可以使用角色来阻止人们看到某些报告
• 用户可以在每次运行报告时更改其参数，也可以使用您为他们设置的默认值
• 报告可以高度自动化，它可以按特定时间表自动运行（例如每周一上午 9 点，或每周日晚上处理结束后的周末）
• 报告可以多种格式提供
• 报表工具可以使用数据库中的存储过程，这些存储过程可以封装业务逻辑

我个人主张使用 Sql Server Reporting Services（2008 版，尽量避免使用 2005），尽管还有其他产品。 SSRS可以与Oracle数据库对话，可以免费获取和使用。

您还模糊地提到了“流程”。我阅读本文的方式是，您在某处运行了一些代码，这些代码将数据从数据库中提取出来，对其进行了一些处理，然后将其放入某个暂存区域-也许 Excel 电子表格是暂存区域，并且进一步的报告来自该暂存区域数据。如果我的解释是正确的，那么上面提到的报告产品（可能还有许多其他产品）就不需要这样做了。