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

J C*_*per 10 .net sql-server rdlc reporting-services

我的老板要我在不久的将来创建一些报告,我想他想使用SQL Server Reporting Services来部署报告.考虑到我们是一个非常小的组织,我不太确定这将是一个好主意,我看不到我们正在充分利用或需要此解决方案提供的功能,如设置用户,组和订阅.

虽然我之前没有使用SSRS,但我已经观看了为期3天的网络研讨会,看起来这是一件很好的事情,对于简单的情况来说很好但是当需求变得更加复杂时会变得很痛苦并且受到限制.我会将报告部署为.net应用程序中的本地报告(.rdlc),因为:

  1. 我宁愿用.NET然后用SQL处理和格式化数据.当然你可以使用CLR,但这条路线看起来似乎更难以维护,而不仅仅像处理.NET应用程序那样处理数据.
  2. 添加参数控件时UI的限制 - 如果我记得你对布局没有太多控制权.

所以我想我的问题是SSRS在什么情况下运作良好,哪些情况不好?我的观点是有效还是我只是怀疑论者?

kbr*_*ton 5

我使用了两者,并发现每种方法都有权衡.

  • 无论出于何种原因,.rdlc的设计者与.rdl的设计者略有不同.当在线示例对您的设计师所做的事情进行假设时,它会变得非常混乱.
  • 如果我试图与客户端无关,我通常会支持SSRS部署的报告,因为基于.rdlc的报告要求您提供客户端.
  • 我通常支持基于.rdlc的独立应用程序报告,特别是对于没有数据中心的客户端.这些应用程序往往是应用程序和数据库都在客户端计算机上的应用程序.
  • 我喜欢LINQ,并且发现它更容易用作基于.rdlc的报告的数据源.
  • 在重构方面,我与基于.rdlc的报告有着爱/恨的关系.将数据结构保存在与报告不同的库中非常重要; 否则,更改属性名称将导致您的构建因报告而失败,但在构建之前,新属性将不会在报告的数据源上可用.
  • 控制客户端(基于.rdlc的报告)为您呈现和收集参数值提供了无限的灵活性,这非常好.

无论如何,我怀疑除了"做有意义的事情"之外,你应该坚持任何教条式的方法.对我来说,实际上,我使用基于.rdlc的小型客户端应用程序报告,并将企业级报告部署到SSRS服务器.

祝好运!


DFo*_*k42 1

您可以像在 Windows 中一样设置报告服务的安全性,因此如果安全性要求发生变化,您只需修改 RS 中的安全性即可。如果它嵌入在应用程序中,您必须更新应用程序(我没有这样做,所以我不知道所有步骤),然后重新部署应用程序以更新安全性。