Microsoft.Reporting. * Vs XML/XSLT

Question

Je voudrais ajouter des fonctionnalités de reporting à une application .NET. Ma source de données est juste le modèle de données de l'application, c'est-à-dire un groupe d'objets qui peuvent avoir été générés ou chargés à partir de n'importe quoi (pas nécessairement à partir d'une base de données).

Le plan initial était de générer un fichier XML de données de rapport à partir de ces objets, puis d'utiliser XSLT pour le transformer en fichier de rapport XHTML. Le rapport peut ensuite être affiché dans l'application avec un contrôle de navigateur.

Cependant, j'ai remarqué qu'il existe des espaces de noms Microsoft.Reporting. * Et d'après ce que j'ai essayé, il semble que les classes et les contrôles dans ce domaine puissent également prendre en charge mes rapports. Serait-ce une bonne idée d'utiliser cela à la place? Cela économisera-t-il du travail par rapport à l'approche XML/XSLT? Quelles sont les limites (le cas échéant) du cadre Microsoft Reporting que je risque de rencontrer?

Answer 1

Un couple de choses à considérer. 1) Reporting Services fait partie de Sql Server, vous risquez d'avoir un problème de licence supplémentaire si vous suivez cette route. 2) Reporting Services peut servir des pages Web, ou être utilisé dans WinForms avec pagination complète, tri, sous-rapports, totaux, etc - c'est vraiment difficile en XSL. Il va aussi bien jouer avec les imprimantes.

3) Les services de reporting sont fournis avec un éditeur WYSIWYG pour générer des rapports. Ce n'est pas parfait par tous les moyens, mais beaucoup plus facile que l'artisanat.

4) L'utilisation de XSL pour créer du XHTML peut être un réel succès en termes de performances. XSL fonctionne sur un Dom XML complet, et peut-être un gros document si vous traitez un rapport multipage. Je m'attends à ce que Reporting Services fonctionne beaucoup plus rapidement.

5) Reporting Services peut tirer parti de l'ensemble de .Net, de sorte que vous pouvez obtenir beaucoup d'autres fonctionnalités gratuitement. En prenant tout ce qui est à bord, l'utilisation de Reporting Services vous fera gagner du temps, à moins que vos exigences de reporting soient très simples. C'est moins amusant quand même.

Answer 2

et ActiveReports (et d'autres outils .NET tiers) peuvent également signaler directement des objets et ont une politique de licence conviviale pour les développeurs.

Answer 3

D'accord avec la plupart des commentaires de MrTelly les exceptions et les ajouts suivants:

• Sauf si vous êtes muet au sujet de votre XSLT et vos données de rapports est énorme (plus de 100 Mo - nu à l'esprit que je suis en parlant des données qui alimentent le rapport et PAS les données sources), les performances ne sont pas susceptibles d'être un problème important. Avec un système de reporting XML/XSLT qui prend les ensembles de données .NET et les transforme en rapports à la volée et avec XSLT correctement écrit, les performances sont souvent inférieures à la seconde (pour les grands jeux de données, il peut être plus long, mais rien d'horrible). . La mise en page de rapport avec une solution XML/XSLT est essentiellement illimitée, avec Reporting Services, vous êtes limité aux constructions dans RDL (Microsoft Report Definition Language). Si vous avez besoin de quelque chose de plus compliqué que les structures de reporting standard, Reporting Services sera frustrant.

Answer 4

semble que vous pouvez également générer le code XML de vos objets, puis créez votre rapport natif ReportViewer de qu'XML ainsi

Rapports du bâtiment à partir de documents XML à l'aide ReportViewer

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