.net - visual - reportviewer c# webform
Sql Server Reporting Services vs Informes a través de la aplicación.NET (5)
Nadie dijo nada sobre Report Builder 2.0 o 3.0. Es una gran aplicación solo para generar informes sin necesidad de SSRS ni nada. Simplemente enciéndalo y configúrelo para consumir cualquier fuente de datos que tenga disponible y listo. Quiero decir, puedes compilar fácilmente este informe en poco tiempo. Piénsalo.
Definitivamente no necesita otra solución .NET personalizada para esto.
Mi jefe quiere que cree algunos informes en el futuro cercano y creo que quiere usar SQL Server Reporting Services para implementar los informes. No estoy tan seguro de que esta sea una gran idea, considerando que somos una organización bastante pequeña y no veo que usemos o necesitemos las características que ofrece esta solución, como la configuración de usuarios, grupos y suscripciones.
Aunque no he usado SSRS antes, he visto un webinar de 3 días y parece que es una de esas cosas que son agradables y aceptables para situaciones simples, pero se vuelve un dolor y demasiado restringido cuando los requisitos se vuelven más complejos. Desplegaría mucho los informes como informes locales (.rdlc) en una aplicación .NET porque:
- Preferiría procesar y formatear datos con .NET y SQL. Claro que puedes usar CLR, pero esta ruta parece ser más difícil de mantener y menos ideal que solo procesar datos como lo haría normalmente en una aplicación .NET.
- Limitaciones en la interfaz de usuario al agregar controles de parámetros: si recuerdo, no tiene mucho control sobre el diseño.
Así que supongo que mi pregunta sería en qué situaciones funciona el SSRS, ¿en qué situaciones no funciona? ¿Son válidos mis puntos o solo soy un escéptico?
Puede configurar la seguridad para los servicios de informes tal como en Windows, de modo que si un requerimiento de seguridad cambia, simplemente puede modificar la seguridad en RS. Si está incrustado en una aplicación, debe actualizar la aplicación (no lo he hecho así que no conozco todos los pasos) y luego volver a implementar la aplicación para actualizar la seguridad.
Tus instintos son buenos, sigue usándolos.
Muchas personas caen en la trampa de empujar la lógica empresarial compleja en SQL y herramientas de informes. El lugar correcto está en el ETL. No se deje intimidar por el término que cubre simples scripts perl ad-hoc para complejos SSIS. Incluso entonces, el 80% del tiempo las personas usarán SSIS para extraer y cargar solo los datos que guardan la transformación para el informe en tiempo de ejecución (¿Por qué estos informes son tan lentos ?!).
Incluso si se ve obligado a servir los datos a través de SSRS, mantenga su capa de transformación separada del informe en la herramienta / idioma de su elección, manteniendo su SQL simple y conciso.
Para una tienda pequeña, aspx probablemente esté bien, pero téngalo en cuenta. Obtiene un montón de cosas gratis de SSRS con seguridad y exportación para sobresalir, lo cual es una gran ventaja para su jefe. Los informes también son un agujero negro de trabajo ocupado. Su primer puñado de informes se multiplican rápidamente para diferentes usuarios y diferentes motivos comerciales y se vuelven inmanejables. Si configura una buena base de SSRS, puede migrar el trabajo a otra persona cuando sea el momento adecuado.
Si estás más interesado, te sugiero que leas el almacenamiento de datos.
Una cosa más. Tenga en cuenta la ejecución de informes contra datos en vivo. Los informes suelen tener un perfil de rendimiento diferente que las consultas OLTP. OLTP = unos pocos registran un momento en el que las consultas de Informes (DW) alguna vez requieren escaneos completos de tablas y pueden causar problemas de bloqueo si no se configuran correctamente.
Tus puntos son válidos
Para una aplicación más pequeña, consideraría usar un control ReportViewer en una aplicación ASP.NET si no necesita todas las comodidades. Incluso desde una perspectiva de mantenimiento: solo tienes que administrar una aplicación. Mi equipo está planeando dejar de usar SSRS.
Sé que algunos de nuestros equipos hermanos tienen informes y estructuras complejas, y necesitan las campanas y silbatos.
Uso un poco de ambos, y he descubierto que hay intercambios con cada enfoque.
- Por alguna razón, el diseñador de .rdlc es un poco diferente al diseñador de .rdl. Puede ser bastante confuso cuando un ejemplo en línea hace suposiciones sobre lo que es su diseñador.
- En general, prefiero los informes implementados por SSRS si intento ser independiente del cliente, ya que los informes basados en .rdlc requieren que usted proporcione el cliente.
- En general, estoy a favor de los informes basados en .rdlc para aplicaciones independientes, especialmente para clientes que no tienen un centro de datos. Estas tienden a ser aplicaciones donde tanto la aplicación como la base de datos están en la máquina del cliente.
- Me gusta LINQ y me resulta más fácil utilizarlo como fuente de datos para informes basados en .rdlc.
- Tengo una relación de amor / odio con los informes basados en .rdlc cuando se trata de refactorización. Mantener sus estructuras de datos en una biblioteca separada de sus informes es importante; de lo contrario, cambiar el nombre de una propiedad provocará que la compilación falle a causa del informe, pero la nueva propiedad no estará disponible en la fuente de datos para el informe hasta que compile.
- El control del cliente (informe basado en .rdlc) le brinda una flexibilidad ilimitada sobre la forma en que presenta y recopila los valores de los parámetros, lo cual es bastante agradable.
En cualquier caso, dudo que haya un enfoque dogmático al que se debe apegar, aparte de "hacer lo que tiene sentido". Para mí, en la práctica, utilizo informes basados en .rdlc para pequeñas aplicaciones cliente, e implemento informes de nivel empresarial en un servidor SSRS.
¡Buena suerte!