.net - Sql Server Reporting Services 与通过 .NET 应用程序进行报告

Question

我的老板希望我在不久的将来创建一些报告，我认为他想使用 SQL Server Reporting Services 来部署这些报告。考虑到我们是一个相当小的组织，而且我看不到我们充分利用或需要该解决方案提供的功能(例如设置用户、组和订阅)，我不太确定这是否是一个好主意。

虽然我以前没有使用过 SSRS，但我看过一个为期 3 天的网络研讨会，看起来它对于简单的情况来说是很好的事情之一，但当需求变得越来越多时，它就会变得痛苦且受到限制更复杂。我更愿意将报告部署为 .net 应用程序中的本地报告 (.rdlc)，因为:

1. 我更愿意使用 .NET 处理和格式化数据，而不是 SQL。当然，您可以使用 CLR，但与我通常在 .NET 应用程序中处理数据相比，这条路线似乎更难维护，而且不太理想。
2. 添加参数控件时 UI 的限制 - 如果我记得您对布局没有太多控制权。

所以我想我的问题是 SSRS 在什么情况下工作得很好，在什么情况下工作得不好？我的观点有效还是我只是持怀疑态度？

Answer 1

我使用了这两种方法，并且发现每种方法都需要权衡。

• 无论出于何种原因，.rdlc 的设计器与 .rdl 的设计器略有不同。当在线示例对您的设计师进行假设时，可能会变得非常困惑。
• 如果我想与客户端无关，我通常会倾向于使用 SSRS 部署的报告，因为基于 .rdlc 的报告要求您提供客户端。
• 我通常喜欢针对独立应用程序使用基于 .rdlc 的报告，尤其是对于没有数据中心的客户。这些应用程序往往是应用程序和数据库都位于客户端计算机上的应用程序。
• 我喜欢 LINQ，并且发现它更容易用作基于 .rdlc 的报告的数据源。
• 在重构方面，我对基于 .rdlc 的报告又爱又恨。将数据结构保存在与报告不同的库中非常重要；否则，更改属性名称将导致您的构建因报表而失败，但在构建之前，新属性在报表的数据源上不可用。
• 通过控制客户端(基于 .rdlc 的报告)，您可以在呈现和收集参数值的方式上获得无限的灵 active ，这非常好。

无论如何，除了“做有意义的事”之外，我怀疑您应该坚持任何教条的方法。对我来说，在实践中，我将基于 .rdlc 的报告用于小型客户端应用程序，并将企业级报告部署到 SSRS 服务器。

祝你好运!