views:

719

answers:

3

I would like to add reporting capabilities to a .NET application. My data source is just the data model of the application, i.e. a bunch of objects that may have been generated or loaded from anything (not necessarily from a database).

The initial plan was to generate a report data XML file from these objects, and then use XSLT to transform this into an XHTML report file. The report can then be shown in the application with a browser control.

However, I've noticed that there exist Microsoft.Reporting.* namespaces and from what I've tried, it seems that the classes and controls in there can also take care of my reporting. Would it be a good idea to use this instead? Will it save work compared to the XML/XSLT approach? What limitations (if any) of the Microsoft Reporting framework am I likely to run into?

+7  A: 

A couple of things to consider.

1) Reporting Services are part of Sql Server, so you may have an extra license issue if you go that route.

2) Reporting Services can serve up web pages, or be used in WinForms with full paging, sorting, sub reports, totals etc etc - that's really hard in XSL. It will also play nicely with printers.

3) Reporting services comes with a WYSIWYG editor to build reports. It's not perfect by any means, but a lot easier than hand crafting.

4) Using XSL to create XHTML can be real performance hit. XSL works on an entire XML Dom, and that maybe a big document if you're dealing with a multipage report. I'd expect Reporting Services to work a lot faster.

5) Reporting Services can leverage the whole of .Net, so you can get a lot of other functionality for free.

Taking all that on board, using Reporting Services will save you time, unless your reporting requirements are very simple. It is less fun though.

MrTelly
I have a little test application which generates a report from a list of objects and it only requires the ReportViewer.exe redistributable to be installed first. The reporting services do not appear to be tied to Sql Server.
Wim Coenen
Is is less fun though? Haha nice.
Pablo Marambio
+1  A: 

Data Dynamics Reports and ActiveReports (and other third party .NET tools) can also report directly off of objects and have a developer-friendly licensing policy.

scott
+2  A: 

Agree with most of MrTelly's comments with the following exceptions and additions:

  • Unless you're dumb about your XSLT and your reporting data is HUGE (100+ MB -- bare in mind I'm talking about the data that feeds the report and NOT the source data), performance isn't likely to be a significant problem. We've built an XML/XSLT reporting system that takes .NET datasets and transforms them to reports on the fly and with properly written XSLT, performance is mostly subsecond (for large datasets it can be longer, but nothing horrible for a web app).

  • Report Layout with an XML/XSLT solution is essentially unlimited, with Reporting Services, you are restricted to the constructs within RDL (Microsoft's Report Definition Language). If you need something more complicated than standard reporting structures, Reporting Services will be frustrating.

Jay Stevens