Microsoft.Reporting.* vs. XML/XSLT

Question

Ich möchte einer .NET-Anwendung Berichtsfunktionen hinzufügen. Meine Datenquelle ist nur das Datenmodell der Anwendung, d.h. eine Reihe von Objekten, die generiert oder aus einer beliebigen Quelle (nicht unbedingt aus einer Datenbank) geladen wurden.

Ursprünglich war geplant, aus diesen Objekten eine XML-Datei mit Berichtsdaten zu erstellen und diese dann mit 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 und von dem, was ich versucht habe, scheint es, dass die Klassen und Steuerelemente in dort kann auch kümmern sich um meine Berichterstattung. Wäre es eine gute Idee, diese stattdessen zu verwenden? Würde es im Vergleich zum XML/XSLT-Ansatz Arbeit sparen? Auf welche Einschränkungen (wenn überhaupt) des Microsoft Reporting Frameworks werde ich wahrscheinlich stoßen?

Answer 1

Ein paar Dinge sind zu beachten.

1) Die Reporting Services sind Teil von Sql Server, so dass Sie möglicherweise ein zusätzliches Lizenzproblem haben, wenn Sie diesen Weg wählen.

2) Reporting Services können Web-Seiten ausgeben oder in WinForms mit vollständiger Seitenumschaltung, Sortierung, Unterberichten, Gesamtsummen usw. verwendet werden - das ist in XSL wirklich schwierig. Sie können auch gut mit Druckern zusammenarbeiten.

3) Die Berichtsdienste verfügen über einen WYSIWYG-Editor zur Erstellung von Berichten. Er ist keineswegs perfekt, aber viel einfacher als Handarbeit.

4) Die Verwendung von XSL zur Erstellung von XHTML kann ein echter Leistungseinbruch sein. XSL arbeitet mit einem ganzen XML-Dom, und das kann ein großes Dokument sein, wenn es sich um einen mehrseitigen Bericht handelt. Ich würde erwarten, dass Reporting Services viel schneller arbeiten.

5) Reporting Services können das gesamte .Net nutzen, so dass Sie eine Menge anderer Funktionen kostenlos erhalten können.

Wenn Sie all dies berücksichtigen, sparen Sie mit den Berichtsdiensten Zeit, es sei denn, Ihre Berichtsanforderungen sind sehr einfach. Allerdings macht es weniger Spaß.

Answer 2

Ich stimme mit den meisten Kommentaren von MrTelly überein, mit den folgenden Ausnahmen und Ergänzungen:

• Solange Sie nicht dumm sind, was XSLT angeht, und Ihre Berichtsdaten RIESIG sind (100+ MB - denken Sie daran, dass ich von den Daten spreche, die den Bericht speisen, und NICHT von den Quelldaten), wird die Leistung wahrscheinlich kein großes Problem sein. Wir haben ein XML/XSLT-Berichtssystem entwickelt, das .NET-Datensätze in Berichte umwandelt, und mit ordnungsgemäß geschriebenem XSLT liegt die Leistung meist unter einer Sekunde (bei großen Datensätzen kann es länger dauern, aber für eine Webanwendung ist das nichts Schlimmes).

• Das Berichtslayout mit einer XML/XSLT-Lösung ist im Wesentlichen unbegrenzt, mit Reporting Services sind Sie auf die Konstrukte in RDL (Microsofts Report Definition Language) beschränkt. Wenn Sie etwas Komplizierteres als die Standard-Berichtsstrukturen benötigen, werden die Reporting Services frustrierend sein.

Answer 3

Datendynamik-Berichte y ActiveReports (und andere .NET-Tools von Drittanbietern) können auch direkt von Objekten berichten und haben eine entwicklerfreundliche Lizenzierungspolitik.

Answer 4

Sie könnten auch die Xml-Datei aus Ihren Objekten generieren und dann Ihren nativen ReportViewer-Bericht aus dieser XMl-Datei erstellen

Berichte aus XML-Dokumenten mit ReportViewer erstellen

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