什么时候使用 RDLC 而不是 RDL 报告?

过去几周我一直在研究 SSRS 2005/2008,并创建了一些服务器端报告。对于某些应用程序,一位同事建议我研究 RDLC 来解决这种特殊情况。我现在试图理解 RDL 和 RDLC 之间的主要区别。

搜索这些信息最多只能得到零碎的信息。我了解到:

  • RDLC 报告不存储有关如何获取数据的信息。
  • RDLC 报告可以由 ReportViewer 控件直接执行。

但是我仍然不完全理解 RDLC 文件与其他相关系统(ReportingServer、源数据库、客户机)之间的关系。

In order to get a good grasp on RDLC files, I would like to know how their use differs from RDL files and in what situation one would choose RDLC over RDL. Links to resources are also welcome.

更新:

在 ASP.NET 论坛上的帖子讨论了同样的问题。从中,我对这个问题有了一些更好的理解。

RDLC 的一个特性是可以在 ReportViewer 控件中运行 完全站在客户一边

  • 这消除了对 ReportingServices 实例的需要,甚至消除了对任何数据库连接的需要,但是:
  • 它还要求必须手动提供报告中所需的数据。

这是一个优点还是一个缺点取决于特定的应用程序。

In my application, an instance of Reporting Services is available anyway and the required data for the reports can easily be pulled from a database. Is there any reason left for me to consider RDLC, or should I simply stick with RDL?

139920 次浏览

我一直认为 RDL 和 RDLC 的不同之处在于,RDL 用于 SQL Server Reporting Services,而 RDLC 在 Visual Studio 中用于客户端报告。实现和编辑器几乎是相同的。RDL代表 Report Defintion LanguageRDLC代表 Report Definition Language Client-side

希望能帮上忙。

根据我的经验,如果在大型报表上需要高性能(这稍微取决于您的客户机规范) ,那么使用 rdlc。另外,rdlc 报告为您提供了对数据的全面控制,您可以通过使用客户端报告来节省浪费的数据库访问等。在我目前正在进行的项目中,一个关键的报告需要大约2分钟才能在服务器端呈现,并且几乎可以在这段时间内删除任何报告服务器。将其切换到客户端呈现,我们可以看到性能接近20-40秒,报表服务器上没有负载,使用的带宽更少,因为只下载数据集。

您的经验可能会有所不同,我发现 rdlc 增加了开发和维护的复杂性,特别是当您的报表被设计为服务器端报表时。

如果您有可用的报表服务基础结构,请使用它。您会发现 RDL 开发更令人愉快一些。您可以预览报告,轻松设置参数等。

对于 VS2008,我相信 RDL 提供了比 RDLC 更好的编辑特性。例如,我可以用 RDL 更改文本框中选定数量文本的粗体,而在 RDLC 中则不可能。

ijklmnop

RDLC: 我要打他-or-abcd efgh ijklmnop (是您唯一的选择)

这是因为 RDLC 使用的是2005年以前的名称空间/格式,而 RDL 使用的是2008年的名称空间/格式。然而,这将与 VS2010改变

上面已经提到了其中的一些观点,但这里是我对 VS2008环境的2美分建议。

RDL (Remote reports): Much better development experience, more flexibility if you need to use some advanced features like scheduling, ad-hoc reporting, etc...

RDLC (Local reports) : 在将数据发送到报表之前对数据进行更好的控制(在将数据发送到报表之前更容易验证或操作数据)。更容易部署,不需要 ReportingServices 实例。

本地报告的一个重大警告是已知的内存泄漏,如果您的客户机将运行大量大型报告,那么这会严重影响性能。这个问题应该通过新的 VS2010版本的报表查看器来解决。

在我的例子中,因为我们有一个 ReportingServices 实例可用,所以我将新报表开发为 RDL,然后将它们转换为本地报表(这很容易) ,并将它们部署为本地报表。

问: RDL 格式和 RDLC 格式有什么区别?

答: RDL 文件是由 SQL 创建的 报表的 Server2005版本 创建 Designer.RDLC 文件 的 VisualStudio2008版本 报表设计器。

RDL 和 RDLC 格式具有相同的 XML 但是,在 RDLC 文件中,有些 值(例如查询文本)是 允许是空的,这意味着 他们还没有马上准备好 发布到报表服务器 缺少的值可以通过 使用 SQL 打开 RDLC 文件 报表的 Server2005版本 (必须将.rdlc 重命名为 。 rdl 第一。)

RDL files are fully compatible with ReportViewer 控件运行库。 但是,RDL 文件不包含一些 的设计时间 ReportViewer 控件依赖于 用于自动生成 数据绑定代码。通过手动绑定 数据,RDL 文件可以在 ReportViewer 控件。新建! 请参阅 RDL 查看器示例程序。

请注意,ReportViewer 控件 不包含任何逻辑 连接到数据库或执行 通过分离出这样的逻辑, ReportViewer 已生成 与所有数据源兼容, including non-database data sources. 然而这意味着什么时候一个 RDL 文件由 ReportViewer 使用 控件,SQL 相关信息 RDL 文件中的 控制,它是宿主 申请人的责任 连接到数据库,执行查询 and supply data to the ReportViewer 以 ADO.NET 的形式控制 数据表。

Http://www.gotreportviewer.com/

虽然我倾向于使用 RDL,因为它看起来更灵活、更容易管理,但是 RDLC 的优势在于它似乎简化了您的许可。因为 RDLC 不需要 ReportingServices 实例,所以使用它不需要 ReportingServices 许可证。

我不确定这是否仍然适用于较新版本的 SQLServer,但是有一次,如果您选择将 SQLServer 数据库和 ReportingServices 实例放在两台单独的机器上,则需要具有两个单独的 SQLServer 许可证:
Http://social.msdn.microsoft.com/forums/en-us/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

对于其他类似的关于 ReportingServices 许可的博客和文章,可以使用 必应

根据我的经验,很少有事情可以同时考虑这两件事:

RDL 报告通常是托管报告。这意味着您需要实现 SSRS 服务器。它们是从 SQLServer 为报表语言构建的 VisualStudio 内置扩展。当您安装 SSRS 时,您应该有一个名为“ BusinessIntelligenceDevelopmentStudio”的附加组件,它使用报表比不使用报表更容易。

R eport

定义

长度

RDL 报告的好处:

  1. 您可以将报表托管在具有为您运行的服务的环境中。
  2. You can configure security on an item or inheriting level to handle security as a standalone concept
  3. 您可以将服务配置为发送电子邮件(只要您拥有可以访问的 SMTP 服务器)并将文件保存在计划中
  4. 您有一个通常称为“ ReportServer”的数据库,您可以在报告发布后查询相关信息。
  5. 在用 ASP.NET,WPF 编写的客户端应用程序中,您仍然可以通过“ ReportViewer”访问这些报告(使用 winform 控件 bleh!)或者温表格。使用 ProcessingMode。遥控器。
  6. 您可以设置用户可以看到和使用的参数,以获得更大的灵活性。
  7. 可以将报表的某些部分配置为用于连接字符串的“数据源”,也可以将 sql 查询、 xml 或其他数据集配置为“数据集”。可以定期存储和配置这些部件和其他部件以缓存数据。
  8. 你可以写作。NET 服务的代理类 http:///ReportServer/ReportingService2010或/ReportExection2005。中创建自己的方法。NET,用于直接从代码中承载 SSRS 报告的服务器的服务中发送、保存或操作 SSRS 数据。 使用 ReportService2010.asmx 以编程方式从 Sharepoint 导出 SSRS 报告

缺点:

  1. SSRS 相对于其他东西来说,在快速提升方面有点不靠谱。大多数人对安全策略和将报表设计为 VS SQL 2005 = VS BIDS 2005、 SQL 2008 = VS BIDS 2008、 SQL 2012 = VS BIDS 2010(LOL)的“附件”感到困惑。
  2. 继续1的政策,为安全设置 IMHO 是愚蠢的过于复杂。有服务器安全性、数据库安全性和角色,两个安全性设置在页面上承载服务。大多数人只建立了一个管理员比不能进入,并想知道为什么其他用户不能。大多数关于 SSRS 的投诉或问题都是从我的经验中总结出来的。
  3. You can use 'expressions' that will supposeduly 'enhance' your report. Often times you do more than a few and your report goes to a crawl in performance.
  4. 您有一组可以执行并导出到的操作。据我所知,如果没有 javascript 黑客攻击,SSRS 就不会在报告上徘徊。
  5. 速度和性能可能会受到影响,因为愚蠢的 SSRS 配置会重复使用系统,而第一次报告有时只是加载站点就需要一段时间。你可以通过改变它来解决这个问题,但是我发现让服务生存下去效果更好。

二。RDLC 报告是没有在任何地方托管的客户端包含的报告。名称中多余的 c 表示“客户”。通常,这是 RDL 语言的一个扩展,仅用于 VisualStudio 客户端应用程序。当您添加“报告”项时,它存在于 VisualStudio 中。

Benefits of RDLC reports:

  1. 您可以将 wcf 服务与数据集连接起来,这要容易得多。
  2. 您可以对数据集进行更多的控制,并且可以直接使用填充了 Entity 框架对象或 ADO.NET 的 POCO 类以及表本身。在将数据绑定到报表之前,可以对数据进行优化。
  3. 您可以在后面的代码中直接使用 add on 来自定义外观。

缺点:

  1. 您需要自己处理参数,虽然您可以实现包装器方法来帮助完成这项工作,但是这比预期的要多一些,而且很不幸。
  2. 除非处于远程模式并访问 RLD 报表,否则用户无法看到“ ReportViewer”控件中的参数。因此,您需要使文本框,下拉列表,单选按钮自己以外的控件传递给它。有些人喜欢这样加控制,我个人不喜欢。
  3. 您需要自己构建任何与服务分发报表有关的操作。电子邮件,订阅,保存。不好意思,你得把这个写进去。NET 或者实现一个代理,从上面已经做到这一点,你可以只是得到使用托管报告。

说实话,我喜欢两者的目的不同。如果我想让分析师们知道一些他们一直在使用的东西,比如图表、图表、钻取和导出到 Excel,我会使用 RDL,让 SSRS 的站点完成处理电子邮件分发的所有跑腿工作。如果我想要一个应用程序,有一个报告部分,我知道应用程序是它自己的模块与规则和治理,我使用一个 RDLC,有参数更小,并驱动用户的决定之前得到的报告部分,他们是什么客户端和站点,然后他们通常只是选择一个时间框架或类型,没有更多。所以一般来说,对于一个复杂的报告,我会使用 RDL,对于一些简单的东西,我会使用 RDLC IMHO。

希望能帮上忙。

如果我们有更少数量的报告,不那么复杂和使用 asp.net 网页。 最好使用 rdlc,原因是我们可以避免维护 RS 实例的报告。 but we have to fetch the data from DB manually and bind it to rdlc.

Cons:designing rdlc in visual studio is little difficult compared to SSrs designer.

Pro:Maintenance is easy. 在从 we 页面导出报告时,观察到与服务器端报告相比,性能有所提高。

如果您想在 asp.net 中使用 report,那么使用.rdl 如果要在报表生成器/报表服务器中使用/view,请使用. rdlc 只要手动转换格式就可以了