Segnala domanda sull'architettura del gestore

Question

Sto tentando di disporre di un servizio ReportHandler per gestire la creazione di report. I report possono avere un numero multiplo e diverso di parametri che è possibile impostare. Nel sistema attualmente esistono diversi metodi di creazione di report (servizi di reportistica MS, report html, ecc.) E il modo in cui i dati vengono generati per ciascun report è diverso. Sto cercando di consolidare tutto in ActiveReports. Non posso alterare il sistema e cambiare i parametri, quindi in alcuni casi otterrò essenzialmente una clausola where per generare i risultati, e in un altro caso otterrò coppie chiave / valore che devo usare per generare i risultati. Ho pensato di utilizzare il modello di fabbrica, ma a causa del diverso numero di filtri di query questo non funzionerà.

Mi piacerebbe avere un singolo ReportHandler che prendesse i miei vari input e sputasse il report. A questo punto non vedo altro che utilizzare una grande istruzione switch per gestire ogni report basato su reportName. Qualche suggerimento su come potrei risolverlo meglio?

Answer 1

Dalla tua descrizione, se stai cercando uno schema che corrisponda meglio di Factory, prova Strategia:

Modello di strategia

1. Il tuo contesto potrebbe essere una classe personalizzata che incapsula e riassume i diversi input del rapporto (potresti utilizzare il modello AbstractFactory per questa parte)
2. La tua strategia potrebbe implementare un numero qualsiasi di diversi filtri di query o logica aggiuntiva necessaria. E se dovessi mai cambiare il sistema in futuro, puoi passare da uno strumento di report all'altro semplicemente creando una nuova strategia.

Spero che ti aiuti!

Answer 2

Oltre al modello di strategia, puoi anche creare un adattatore per ciascuna delle tue soluzioni sottostanti. Quindi utilizzare la strategia per variare. Ho creato simili con ogni soluzione di report supportata da quelli che ho chiamato motori, oltre alla soluzione di report variabile abbiamo anche una soluzione di archiviazione variabile - l'output può essere archiviato in SQL Server o file system. Suggerirei di utilizzare un contenitore e quindi inizializzarlo con il motore corretto, ad esempio:

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

quindi i delegati di ReportContainer lavorano ai motori dipendenti ...

Answer 3

Abbiamo avuto un problema simile e abbiamo seguito il concetto di "connettori" che sono interfacce tra l'applicazione principale del generatore di report e i diversi motori di report. In questo modo, siamo stati in grado di creare un "server di report universale" applicazione. Dovresti dare un'occhiata a www.versareports.com.