过去几周我一直在研究 SSRS 2005 / 2008,并创建了一些服务器端报告。对于某些应用,一位同事建议我针对特定情况研究 RDLC。我现在正在尝试了解 RDL 和 RDLC 之间的主要区别。
搜索这些信息最多只能得到零散的信息。我了解到:
- RDLC 报告不存储有关如何获取数据的信息。
- RDLC报告可以直接由ReportViewer控件执行。
但我仍然不完全理解RDLC文件和其他相关系统(报表服务器、源数据库、客户端)之间的关系。
为了更好地掌握 RDLC 文件,我想知道它们的使用与 RDL 文件有何不同,以及在什么情况下会选择 RDLC 而不是 RDL。也欢迎提供资源链接。
Update:
A ASP.NET 论坛上的主题讨论同一问题。从中,我对这个问题有了更多的了解。
RDLC的一个特点是它可以运行完全客户端在 ReportViewer 控件中。
- 这消除了对 Reporting Services 实例的需要,甚至消除了对任何数据库连接的需要,但是:
- 它增加了必须手动提供报告中所需数据的要求。
这是优点还是缺点取决于特定的应用。
在我的应用程序中,无论如何都有一个 Reporting Services 实例可用,并且可以轻松地从数据库中提取报告所需的数据。我还有什么理由考虑 RDLC,还是应该坚持使用 RDL?
根据我的经验,这两件事需要考虑的事情很少:
I. RDL 报告一般为 HOSTED 报告。这意味着您需要实施 SSRS 服务器。它们是来自 SQL Server 的 Visual Studio 的内置扩展,用于报告语言。当您安装 SSRS 时,您应该有一个名为“Business Intelligence Development Studio”的附加组件,使用报告比没有它更容易。
R eport
D定义
L angauge
RDL 报告的优点:
- 您可以将报告托管在为您运行服务的环境中。
- 您可以在项目或继承级别上配置安全性,以将安全性作为独立概念来处理
- 您可以配置该服务来发送电子邮件(前提是您有可以访问的 SMTP 服务器)并按计划保存文件
- 您有一个通常称为“ReportServer”的数据库,您可以在发布后查询有关报告的信息。
- 您仍然可以通过使用 ASP.NET、WPF(带有 winform 控件 bleh!)或使用“ProcessingMode.Remote”的 .NET 中的 Winform 编写的客户端应用程序中的“ReportViewer”来访问这些报告。
- 您可以设置用户可以看到和使用的参数以获得更大的灵活性。
- 您可以将报表的一部分配置为用于连接字符串的“数据源”,也可以将 SQL 查询、XML 或其他数据集配置为“数据集”。这些部分和其他部分可以被存储和配置为定期缓存数据。
- 您可以编写服务 http:// /ReportServer/ReportingService2010 或 /ReportExecution2005 的 .NET 代理类。然后,您可以在 .NET 中编写自己的方法,用于直接通过代码托管 SSRS 报告的服务器的服务通过电子邮件发送、保存或操作 SSRS 数据。使用 ReportService2010.asmx 以编程方式从共享点导出 SSRS 报告
缺点:
- 与其他东西相比,SSRS 在快速启动方面有点不稳定。大多数人对安全策略和将报告设计为 VS 的“附加”感到困惑。 SQL 2005 = VS BIDS 2005,SQL 2008 = VS BIDS 2008,SQL 2012 = VS BIDS 2010(笑)。
- 继续 1 恕我直言,安全设置策略过于复杂。有服务器安全性、数据库安全性和角色,以及为服务托管的页面上的两个安全设置。大多数人只设置了一个管理员,却无法进入,并想知道为什么其他用户不能进入。根据我的经验,关于 SSRS 最常见的投诉或问题与进入有关。
- 您可以使用“表达式”来“增强”您的报告。很多时候,你做的事情太多了,你的报告的性能就会变得很低。
- 您可以做并导出一定数量的事情。据我所知,如果没有 javascript hack,SSRS 就不会悬停在报告上。
- 速度和性能可能会受到影响,因为愚蠢的 SSRS 配置会回收系统,并且第一份报告有时可能需要一段时间才能加载站点。您可以通过更改它来解决这个问题,但我发现为其提供保持活动服务效果更好。
二. RDLC 报告是客户端包含的报告,不在任何地方托管。名称中额外的 c 表示“客户端”。通常,这是 RDL 语言的扩展,仅在 Visual Studio 客户端应用程序中使用。当您添加“报告”项时,它就存在于 Visual Studio 中。
RDLC 报告的优点:
- 您可以更轻松地将 wcf 服务连接到数据集。
- 您可以更好地控制数据集,并且可以直接使用填充有实体框架对象或 ADO.NET 的 POCO 类以及表本身。您可以在将数据绑定到报告之前对数据进行优化。
- 您可以直接在代码后面添加附加组件来自定义外观。
缺点:
- 您需要自己处理参数,虽然您可以实现包装器方法来帮助跑腿工作,但不幸的是,这比预期的要多一些。
- 用户无法查看“ReportViewer”控件中的参数,除非它处于远程模式并访问 RLD 报告。因此,您需要在控件外部自己制作文本框、下拉菜单、单选按钮以传递给它。有些人喜欢这样加控制,我个人不喜欢。
- 任何您想要为分发报告提供服务的事情都需要您自己构建。发送电子邮件、订阅、保存。抱歉,您需要在 .NET 中构建它,否则实现一个已经从上面执行此操作的代理,您可能只是使用托管报告。
老实说,我出于不同的目的都喜欢两者。如果我想要向分析师提供一些他们一直使用的东西,并调整图形、图表、向下钻取并导出到 Excel,我会使用 RDL,并且让 SSRS 的站点完成处理电子邮件分发的所有跑腿工作。如果我想要一个具有报告部分的应用程序,并且我知道该应用程序是它自己的具有规则和治理的模块,我会使用 RDLC 并让参数更小,并由用户在进入报告部分之前做出的决策驱动他们所在的客户和网站,然后他们通常只是选择一个时间范围或类型,仅此而已。因此,一般来说,复杂的报告我会使用 RDL,而对于简单的报告,我会使用 RDLC 恕我直言。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)