2009-01-26 45 views
6

Me gustaría agregar capacidades de informes a una aplicación .NET. Mi fuente de datos es solo el modelo de datos de la aplicación, es decir, un conjunto de objetos que pueden haber sido generados o cargados desde cualquier cosa (no necesariamente desde una base de datos).Microsoft.Reporting. * Vs XML/XSLT

El plan inicial era generar un archivo XML de datos de informe a partir de estos objetos, y luego usar XSLT para transformarlo en un archivo de informe XHTML. El informe puede mostrarse en la aplicación con un control de navegador.

Sin embargo, me he dado cuenta de que existen espacios de nombres Microsoft.Reporting. * Y por lo que he probado, parece que las clases y controles allí también pueden encargarse de mis informes. ¿Sería una buena idea usar esto en su lugar? ¿Ahorrará trabajo en comparación con el enfoque XML/XSLT? ¿Qué limitaciones (si corresponde) del marco de Microsoft Reporting es probable que encuentre?

Respuesta

7

Un par de cosas a considerar.

1) Los servicios de informes son parte del servidor Sql, por lo que puede tener un problema de licencia adicional si toma esa ruta.

2) Reporting Services puede servir páginas web, o ser utilizado en WinForms con paginación completa, clasificación, informes secundarios, totales, etc., eso es muy difícil en XSL. También jugará muy bien con impresoras.

3) Los servicios de informes vienen con un editor WYSIWYG para generar informes. No es perfecto de ninguna manera, pero es mucho más fácil que hacerlo a mano.

4) Usar XSL para crear XHTML puede ser un golpe de rendimiento real. XSL funciona en una Dom XML completa, y tal vez sea un gran documento si se trata de un informe de varias páginas. Esperaría que Reporting Services funcione mucho más rápido.

5) Reporting Services puede aprovechar toda .Net, por lo que puede obtener muchas otras funcionalidades de forma gratuita.

Tomando todo eso a bordo, el uso de Reporting Services le ahorrará tiempo, a menos que sus requisitos de informes sean muy simples. Sin embargo, es menos divertido.

+0

tengo una pequeña aplicación de prueba que genera un informe a partir de una lista de objetos y solo requiere que se instale primero la redistribuible ReportViewer.exe. Los servicios de informes no parecen estar vinculados al servidor Sql. –

+1

¿Aunque es menos divertido? Jaja bueno. –

1

Data Dynamics Reports y ActiveReports (y otras herramientas .NET de terceros) también pueden informar directamente de objetos y tienen una política de licencia amigable para desarrolladores.

4

acuerdo con la mayoría de los comentarios de MrTelly con las siguientes excepciones y adiciones:

  • A menos que usted es mudo sobre su XSLT y los datos de informes es enorme (más de 100 MB - desnudo en cuenta que soy hablando de los datos que alimenta el informe y NO de los datos fuente), el rendimiento no es probable que sea un problema importante. Hemos creado un sistema de informes XML/XSLT que toma conjuntos de datos .NET y los transforma en informes sobre la marcha y con XSLT correctamente escrito, el rendimiento es principalmente subsegundo (para grandes conjuntos de datos puede ser más largo, pero nada horrible para una aplicación web) .

  • El diseño de informes con una solución XML/XSLT es esencialmente ilimitado, con Reporting Services, usted está restringido a las construcciones dentro de RDL (Lenguaje de definición de informes de Microsoft). Si necesita algo más complicado que las estructuras de informes estándar, Reporting Services será frustrante.

Cuestiones relacionadas