ReportViewer Web 控件是否可以接受企业 Web 应用程序
我一直在 Webforms 应用程序中尝试使用 ReportViewer 控件,该应用程序通过报表服务器远程运行报表。感觉 ReportViewer 中的参数接口受到限制。我认为另一种选择是创建我自己的 Web 表单控件,它将参数传递给 ReportViewer 并绕过默认参数接口。我对 SSRS 的经验非常少,我想知道这是否是一个可行的解决方案,或者是否会带来麻烦。 (即新的报告可能导致必须创建新的用户界面)。我想我的问题是报表查看器中的标准用户界面是否适合企业级应用程序。我不是在谈论分页控件,而是在谈论下拉列表和复选框列表。
I have been experimenting with the ReportViewer control in a webforms applications which is running reports remotely through a Report Server. It feels like the Parameter interface in the ReportViewer is limiting. I think another alternative is to create my own web form controls which pass parameters to the ReportViewer and bypass the default parameter interface. My experience with SSRS is very minimal and I'm wondering if this is a viable solution, or is it asking for trouble. (ie new reports could result in having to create new UI's). I guess my question is whether or not the standard user interface in the report viewer is acceptable for enterprise level applications. I'm not talking about the paging controls, more about the drop down lists and check box lists.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您的报告通常使用简单的参数集,则默认界面可以很好地工作(特别是如果您的用户更精明的话)。但更大、更复杂的参数集很快就会在默认界面中变得难以承受(如果您不希望用户如此精明,这可能是一个更大的问题)。
我在处理大量报告时遇到了类似的问题。有些可能非常简单(IE,没有参数或简单的日期范围),有些可能非常复杂(超过 25 个参数)。
我们达成的解决方案是编写一个 ASP.NET 报表菜单应用程序,该应用程序从 SSRS 检索大多数报表的参数,并将它们动态地呈现给用户。有些报告对此来说太复杂了,所以我们更进一步,为它们编写了 WebUserControls,这进一步简化了用户的参数。这样,大多数报告不需要额外的干预,而对于那些需要额外干预的报告,我们拥有轻松创建包装器的框架。
下面是如何通过 SSRS Web 服务获取给定报表的参数的示例:
您可以使用上述方法获取所有参数,然后根据需要显示它们。然后您所要做的就是收集结果、验证它们并将它们传递给 ReportViewer。
If your reports typically use simple parameter sets, the default interface can work well (especially if your users are more savvy). But larger and more complicated parameter sets can quickly become overwhelming in the default interface (which can be an even bigger problem if you don't expect your users to be so savvy).
I faced a similar problem with a large set of reports. Some can be very simple (I.E., no parameters or a simple date range) and some can be hideously overcomplicated (25+ parameters).
The solution that we reached was to write an ASP.NET report menu application which retrieved the Parameters from SSRS for most reports and dynamically presented them to the users. Some reports were too complicated for this, so we went further and wrote WebUserControls for them which went further in simplifying the parameters for the users. This way, most Reports didn't require extra intervention, and for those that did, we had the framework for easily creating a wrapper.
Here's an example of how to get the parameters for a given report through the SSRS Web Service:
You can use the above method to get all of the parameters and then display them as you see fit. Then all you have to do is collect the results, validate them, and pass them to a ReportViewer.