Pergunta

Eu estou tentando ter um serviço ReportHandler para lidar com a criação de relatórios. Os relatórios podem ter vários, número de parâmetros que podem ser definidos diferentes. No sistema actualmente existem vários métodos diferentes de criação de relatórios (MS Reporting Services, relatórios HTML, etc) e a maneira como os dados são gerados para cada relatório é diferente. Eu estou tentando consolidar tudo em ActiveReports. Eu não pode alterar o sistema e alterar os parâmetros, de modo que, em alguns casos I essencialmente terá uma cláusula WHERE para gerar os resultados, e em outro caso vou receber pares de chave / valor que eu devo usar para gerar os resultados. Pensei em usar o padrão de fábrica, mas por causa do número diferente de consulta filtra isso não vai funcionar.

Eu adoraria ter um único ReportHandler que levaria meus variadas entradas e cuspir relatório. Neste momento eu não estou vendo nenhuma outra maneira do que usar uma instrução switch grande para lidar com cada relatório com base no reportName. Todas as sugestões como eu poderia resolver isso melhor?

Foi útil?

Solução

De sua descrição, se você está procurando um padrão que corresponde melhor do que Factory, tente Estratégia:

padrão de estratégia

  1. O contexto pode ser uma classe personalizada que encapsula e abstrai as diferentes entradas do relatório (você pode usar o padrão AbstractFactory para esta parte)
  2. O estratégia pode implementar qualquer número de filtros de consulta diferentes ou lógica adicional necessários. E se você precisar mudar o sistema no futuro, você pode alternar entre as ferramentas de relatório, basta criar uma nova estratégia.

Espero que ajude!

Outras dicas

Além do padrão de estratégia, você também pode criar um adaptador para cada uma das suas soluções subjacentes. Em seguida, use estratégia para variá-los. Eu construí semelhante com cada solução de relatório que está sendo suportado pelo que chamei motores, Além da solução de relatório variável temos solução de armazenamento variável, bem como - saída pode ser armazenado no servidor SQL ou sistema de arquivos. Gostaria de sugerir o uso de um recipiente, em seguida, inicializando-lo com o motor correto, por exemplo:.

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);

delegados, em seguida, ReportContainer trabalhar para o dependente motores ...

Nós tivemos um problema semelhante e foi com o conceito de "conectores" que são interfaces entre o aplicativo gerador de relatório principal e os diferentes mecanismos de relatório. Ao fazer isso, fomos capazes de criar um aplicativo "servidor de relatório universal". Você deve verificá-la em www.versareports.com.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top