a dónde iría el código de generación de informes.

Question

Tengo una solución de estudio visual con los siguientes proyectos:

1. UI
2. DataAccess
3. BusiessLogic
4. BusinessObjects

Ahora tengo un montón de código que genera informes que se envían por correo electrónico o se guardan como archivos csv.

Estas clases ReportGenerators toman objetos de negocios y generan archivos o cadenas.

¿en qué proyecto los pondrías? Me estoy inclinando hacia una respuesta pero ¿quería ver lo que otros pensaban?

Answer 1

Crearía un proyecto de informes por separado. No pertenece a la interfaz de usuario (supongo que se ejecutan en segundo plano), es efectivamente una capa de "lógica de informes".

Si piensa en cómo podría apoyar los informes, es posible que desee un servicio back-end, pero también puede exponer los datos a través de un servicio web en el futuro. Si necesita proporcionar a los usuarios una función de informes front-end, se conecta a la lógica de informes como lo haría con una interfaz de usuario normal: > Lógica - > Arquitectura de acceso a datos.

Además, si separa su código de informes, puede extraerlo a un nivel de informes dedicado en el futuro.

Answer 2

A está de acuerdo con la publicación de manwood: debe crearlos como informes (si es necesario, coloque un sproc detrás de los informes) por los siguientes motivos:

• Puede ejecutar los informes y mostrar a través del ReportViewer controlar. Esto es bastante sencillo de hacer.

• Usted (y lo más importante otras personas apoyando la aplicación) puede ampliar la aplicación con más informes sin tener que liberar Otra compilación de la aplicación. Esta es una característica bastante útil si no desea estar vinculado a la compatibilidad de la aplicación.

• Puede publicar los informes a través de servicios de informes también.

• Obtiene todas las opciones de exportación de datos de servicios de informes (Excel, csv, pdf, etc.) con los informes Marco de servicios.