Microsoft.Reporting. * Vs XML/XSLT

Question

Ich möchte Berichtsfunktionen zu einer .NET-Anwendung hinzufügen. Meine Datenquelle ist nur das Datenmodell der Anwendung, d. H. Eine Gruppe von Objekten, die möglicherweise von irgend etwas erzeugt oder geladen wurden (nicht notwendigerweise von einer Datenbank).

Der ursprüngliche Plan bestand darin, eine Berichtsdaten-XML-Datei aus diesen Objekten zu erstellen und diese dann mithilfe von XSLT in eine XHTML-Berichtsdatei umzuwandeln. Der Bericht kann dann in der Anwendung mit einem Browser-Steuerelement angezeigt werden.

Allerdings habe ich bemerkt, dass es Microsoft.Reporting. * Namespaces gibt und von dem, was ich ausprobiert habe, scheint es, dass die Klassen und Kontrollen dort auch für meine Berichterstattung sorgen können. Wäre es eine gute Idee, dies stattdessen zu verwenden? Wird es im Vergleich zum XML/XSLT-Ansatz Arbeit sparen? Auf welche Einschränkungen (falls vorhanden) des Microsoft Reporting-Frameworks werde ich wahrscheinlich stoßen?

Answer 1

Ein paar Dinge zu beachten.

1) Reporting Services sind Teil von Sql Server. Sie können daher ein zusätzliches Lizenzproblem haben, wenn Sie diese Route gehen.

2) Reporting Services kann Webseiten bereitstellen oder in WinForms mit vollständiger Paging, Sortierung, Unterberichten, Summen usw. verwendet werden - das ist wirklich schwer in XSL. Es wird auch gut mit Druckern spielen.

3) Reporting Services verfügt über einen WYSIWYG-Editor zum Erstellen von Berichten. Es ist nicht perfekt, aber viel einfacher als Hand-Crafting.

4) Die Verwendung von XSL zur Erstellung von XHTML kann eine echte Leistungseinbuße sein. XSL arbeitet mit einem ganzen XML-Dom, und das ist vielleicht ein großes Dokument, wenn Sie mit einem mehrseitigen Bericht zu tun haben. Ich würde erwarten, dass Reporting Services viel schneller arbeiten.

5) Reporting Services können das gesamte .Net nutzen, so dass Sie viele andere Funktionen kostenlos erhalten können.

Wenn Sie all dies nutzen, sparen Sie mit Reporting Services Zeit, es sei denn, Ihre Berichtsanforderungen sind sehr einfach. Es macht aber weniger Spaß.

Answer 2

Data Dynamics Reports und ActiveReports (und andere .NET-Tools von Drittanbietern) können auch direkt von Objekten berichten und haben eine entwicklerfreundliche Lizenzierungsrichtlinie.

Answer 3

Vereinbaren Sie mit den meisten MrTelly Kommentare mit folgenden Ausnahmen und Ergänzungen:

• Wenn Sie nicht über Ihre XSLT stumm sind und Ihre Berichtsdaten ist riesig (über 100 MB - daran denkt, ich bin Wenn Sie über die Daten sprechen, die den Bericht und NICHT die Quelldaten liefern, ist die Leistung wahrscheinlich kein signifikantes Problem. Wir haben ein XML/XSLT-Berichterstellungssystem entwickelt, das .NET-Datasets in Echtzeit in Berichte umwandelt und mit ordnungsgemäß geschriebenem XSLT die Leistung in der Regel unterschreitet (bei großen Datasets kann es länger sein, aber nichts Schreckliches für eine Web-App) .

• Bericht Layout mit einer XML/XSLT-Lösung ist im Wesentlichen unbegrenzt, mit Reporting Services sind Sie auf die Konstrukte innerhalb von RDL (Microsoft's Report Definition Language) beschränkt. Wenn Sie etwas komplizierteres als standardmäßige Berichtsstrukturen benötigen, wird Reporting Services frustrierend sein.

Answer 4

scheint, dass Sie auch die XML-Daten aus Ihren Objekten erzeugen könnten und dann Ihre Mutter aus diesen XMl Reportviewer-Bericht erstellen und

Berichterstellung von XML-Dokumenten mit Report

http://www.c-sharpcorner.com/UploadFile/mahesh/XmlReports04182007115639AM/XmlReports.aspx