Informar la pregunta de arquitectura del controlador

Question

Estoy intentando tener un servicio ReportHandler para manejar la creación de informes. Los informes pueden tener múltiples y diferentes números de parámetros que podrían establecerse. En el sistema actualmente hay varios métodos diferentes para crear informes (servicios de informes de MS, informes html, etc.) y la forma en que se generan los datos para cada informe es diferente. Estoy tratando de consolidar todo en ActiveReports. No puedo alterar el sistema y cambiar los parámetros, por lo que en algunos casos esencialmente obtendré una cláusula where para generar los resultados, y en otro caso obtendré pares clave / valor que debo usar para generar los resultados. Pensé en usar el patrón de fábrica, pero debido a la cantidad diferente de filtros de consulta, esto no funcionará.

Me encantaría tener un único ReportHandler que tomaría mis variados aportes y escupiría el informe. En este punto, no veo otra forma que no sea usar una declaración de cambio grande para manejar cada informe basado en reportName. ¿Alguna sugerencia de cómo podría resolver esto mejor?

Answer 1

De su descripción, si está buscando un patrón que coincida mejor que Factory, intente Estrategia:

Patrón de estrategia

1. Su contexto podría ser una clase personalizada que encapsule y resuma las diferentes entradas del informe (puede usar el patrón AbstractFactory para esta parte)
2. Su estrategia podría implementar cualquier número de filtros de consulta diferentes o lógica adicional necesaria. Y si alguna vez necesita cambiar el sistema en el futuro, puede cambiar entre las herramientas de informes simplemente creando una nueva estrategia.

¡Espero que eso ayude!

Answer 2

Además del patrón de estrategia, también puede crear un adaptador para cada una de sus soluciones subyacentes. Luego usa la estrategia para variarlos. He construido de manera similar con cada solución de informe compatible con lo que llamé motores. Además de la solución de informe variable, también tenemos una solución de almacenamiento variable: la salida se puede almacenar en el servidor SQL o en el sistema de archivos. Sugeriría usar un contenedor y luego inicializarlo con el motor correcto, por ejemplo:

public class ReportContainer{
          public ReportContainer ( IReportEngine reportEngine, IStorageEngine storage, IDeliveryEngine delivery...)
}
}

/// In your service layer you resolve which engines to use
// Either with a bunch of if statements / Factory / config ... 

IReportEngine rptEngine = EngineFactory.GetEngine<IReportEngine>( pass in some values)

IStorageEngine stgEngine = EngineFactory.GetEngine<IStorageEngien>(pass in some values)

IDeliverEngine delEngine = EngineFactory.GetEngine<IDeliverEngine>(pass in some values)



ReportContainer currentContext = new ReportContainer (rptEngine, stgEngine,delEngine);

luego los delegados de ReportContainer trabajan en los motores dependientes ...

Answer 3

Tuvimos un problema similar y seguimos con el concepto de "conectores". que son interfaces entre la aplicación principal del generador de informes y los diferentes motores de informes. Al hacer esto, pudimos crear un "servidor de informes universal". solicitud. Debe consultarlo en www.versareports.com.