适用于 .Net 的跨浏览器基于 HTML 的报告

发布于 2024-10-20 18:19:25 字数 335 浏览 1 评论 0原文

我们正在开发复杂的解决方案,其中包含基于 ASP.Net 的服务器端和多个客户端应用程序(Delphi、.Net、iOS、BlackBerry、Android 等)。我们需要一些适用于每种类型客户的通用报告解决方案。显然,我们需要一些报告组件来在服务器端生成基于 HTML 的报告。此外,如果能够不仅在服务器端生成报告,而且至少在客户端(至少为我们的 .Net 客户端)生成报告,那就太好了。

换句话说,是否有一些足够灵活的 .Net 组件可以满足我们的期望?我了解 FastReports.Net 和 CrystalReports,但我想知道它们真正跨浏览器的能力。甚至可以使用某些模板引擎来生成此类报告。

有什么建议吗?

We are working on complex solution that contains ASP.Net-based server-side and several client applications (Delphi, .Net, iOS, BlackBerry, Android etc.). We need some universal reporting solution applicable to each type of client. Obviously, we need some reporting component to generate HTML-based reports at server-side. Also, it would be great to have possibility to generate reports not only at server-side, but at client-side at least for our .Net client.

In other words, is there some .Net component, flexible enough to meet our expectations? I know about FastReports.Net and CrystalReports, but I am wondering about their ability to be really cross-browser. It is possible to use even some template engine to generate such reports.

Any advices?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

木森分化 2024-10-27 18:19:25

我的公司已经使用 HTML、Javascript 和各种后端服务器技术完成了多个类似的报告。后端技术确实无关紧要,它所做的只是运行查询并返回数组或 JSON。我们在前端使用HighCharts,这是一种任何客户端都可以使用的可视化数据的绝佳方式。对于原始数据输出,我们利用 DataTables,它取得了压倒性的成功,并获得了客户的普遍良好反馈。

有一些类似于 Crystal 的通用数据报告工具,包括可以部署用于报告的 Infragistics 和 Jasper。然而,从 UI 的角度来看,我警告您不要采用一体化解决方案。我们研究了几种基于 Java 且可以普遍部署在几乎任何环境中的工具,其中 Jasper 是主要工具。然而,我们发现它过于臃肿、过于复杂,而且它输出的结果远低于 100% html 兼容,更不用说它需要花费大量时间来安装、配置和学习。

当你认真对待它时,我们应用程序的客户无论如何都只寻找 10-15 个特定报告,因此“推出我们自己的”报告并不需要太多额外的工作,我们知道这些报告足够具体以改善用户体验同时控制 UI 和合规性的各个方面。 Jasper 所做的报告相对平淡,而我可以通过 CSS 随意处理样式,以及通过表示层中的 DataTable(通过 Ajax 与后端对话)随意处理样式以及所有自定义排序、过滤等。 除了 UI 优势之外,速度也得到了提高建造我们自己的汽车就像将法拉利与起亚进行比较。对于用户端报告,可以轻松构建表单或其他输入元素,将用户输入输入到组装和输出数据的函数中。

是的,这需要时间。然而,当您考虑必要的软件许可证、配置时间和培训时间时,如果您的开发人员足够高效,那么这一切就变得很麻烦。就我而言,该公司遥遥领先。

因此,最重要的是,我会坐下来询问有关它必须有多具体、您对标准的关注程度、软件包可能对资源产生多大影响以及通用解决方案的成本效益如何等问题。然后,客观地将其与本土解决方案进行比较并运行数字。仅仅因为一个软件包声称“快速且简单”并不总是意味着它确实如此。祝你好运。

My company has accomplished several similar reports with HTML, Javascript, and various back-end server technologies. The back-end technology is really irrelevant, all it is doing is running the queries and returning arrays or JSON. We use HighCharts on the front end, which is a wonderful way to visualize data in a method that any client can use. For raw data outputs, we leverage DataTables, which has been an overwhelming success and has gained universally good feedback with clients.

There --are-- universal data reporting tools similar to Crystal including Infragistics and Jasper that could be deployed for reporting. However, from a UI standpoint, I caution you about going with an all-in-one solution. We researched several tools that were Java-based and could be universally deployed in just about any environment, with Jasper being the main one. However, we found it to be bloated, overly complicated, and it output results that were far less than 100% html compliant, not to mention it would take significant time to install, configure, and learn.

When you get down to it, the clients of our app were only looking for 10-15 specific reports anyway, so it wasn't THAT much extra work to "roll our own" that we knew would be specific enough to improve the user experience while controlling all aspects of the UI and compliance. Where Jasper did relatively bland reports, I can handle styles at will via CSS as well as all custom sorting, filtering, etc via the DataTables in the presentation layer (which talks to the backend via Ajax) Besides the UI advantages, the speed improvement gained by building our own is like comparing a Ferrari to a Kia. And for user-side reports it's easy to build forms or other input elements that will get user input to functions that assemble and output the data.

Yes, it will take time. However, when you consider the necessary licenses for software, time for config, and training hours, it becomes a wash if your developer is efficient enough. In my case, the company came out quite a ways ahead.

So, bottom line, I'd sit down and ask questions about how specific it has to be, how concerned you are about standards, how much of a resource impact a package might have, and how cost effective a universal solution is. Then, objectively compare it to a home-grown solution and run the numbers. Just because a package claims to be "quick and easy" doesn't always mean it is. Good Luck.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文