Sostituzione per interruttore grande?

Question

Ho una pagina denominata "ReportController.aspx" il cui scopo è di creare un'istanza di un report (classe) in base a parametri stringa di query

 switch (Request.QueryString["Report"]) 
     {     
      case "ReportA": 
       CreateReportAReport("ReportA's Title"); 
       break; 
      case "ReportB": 
       CreateReportBReport("ReportB's Title"); 
       break;     
      case "ReportC": 
       CreateReportCReport("ReportC's Title"); 
       break; 
      case "ReportD": 
       CreateReportDReport("ReportD's Title"); 
       break; 
       ... 

In pratica, ogni volta che è necessario un nuovo rapporto ci sarà questo overhead di aggiunta un caso e aggiungendo un metodo. Questa dichiarazione di commutazione potrebbe essere molto lunga. Ho letto che è possibile utilizzare un dizionario per mappare un report in?. Come apparirebbe usando un dizionario (supponendo che questo sia un modo migliore).

Inoltre, il metodo CreateReportXReport passa fondamentalmente un gruppo di valori QueryString aggiuntivi al costruttore della classe del report (ogni classe di report ha un costruttore diverso).

Answer 1

Partendo dal presupposto che tutti i rapporti implementare IReport, è possibile farlo utilizzando Func<IReport>, in questo modo:

IDictionary<string,Func<IReport>> dictToReport = new Dictionary { 
    {"ReportA",() => CreateReportAReport("ReportA's Title") } 
, {"ReportB",() => CreateReportBReport("ReportB's Title") } 
, ... 
}; 

È quindi possibile sostituire l'interruttore con questo codice:

var myReport = dictToReport[Request.QueryString["Report"]](); 

Answer 2

Non c'è niente da fare intorno dover digitare le nuove informazioni da qualche parte; la chiave è farla uscire dal codice, per evitare di ricompilare e ridistribuire per un cambiamento così banale.

Alcune buone opzioni sono elencare questi valori in un file di configurazione XML, o, meglio ancora, nel database.

Probabilmente vorrai compilare un dizionario con questi dati, qualunque sia la fonte. Questa volontà:

• Lo rendono facile da memorizzare nella cache
• rendono pulito, codice veloce

Quando arriva il momento di tirare i dati di configurazione in codice, che ci si aggiungono elementi Dizionario in questo modo:

Dictionary<string, IReportCreator> = configDataGetter.GetReportDataFromDB(). 
    ToDictionary(r => r.Name, myReportCreatorFactory(r => r.ReportID)) 

Questo esempio presuppone i dati ottenendo come oggetto entità di qualche tipo, e l'utilizzo di una fabbrica che userebbe un strategy pattern per il vostro codice che crea RELAZIONE ts. C'è un sacco di modi in cui potresti farlo naturalmente.

Immagino che i report siano troppo estesi, vari e di natura diversa che non è possibile inserire solo sql e il building block di stile nel db?

Modifica sulla base di commenti di OP:

Ah, Gotcha. Beh, non so quanto tempo hai, ma tanto quanto puoi spingere tutto in una sorta di factory, hai opzioni migliori che avrai in seguito. Ho intenzione di darti alcuni pensieri che, si spera, aiuteranno, da cose simili che ho fatto. Ogni passaggio è un miglioramento in sé, ma anche un piccolo passo per separare davvero la logica del report da questo codice shell. Inoltre, posso vedere che sai già cosa stai facendo e sono sicuro di sapere cosa dirò di seguito, ma non so cosa tu sappia e sarà utile per gli altri.

Prima di tutto, estrai qualsiasi bit di informazioni dal codice a db (se non lo hai già fatto) e aggiungerai altri campi DB (e una tabella o due) mentre migliori la tua configurazione.

Forse lo sapete già, ma lo menzionerò per altri, per verificare lo schema di strategia di cui sopra. È possibile avere la logica personalizzata di ciascuna "funzione di report" effettivamente nel costruttore delle varie classi di strategia. Verrebbero tutti ereditati dal proprio ReportGenerator di base (o dotati di un'interfaccia IReportGenerator comune). Possono e dovrebbero condividere lo stesso costruttore; i vari parametri del rapporto verrebbero gestiti da un parametro del dizionario dei tipi. L'implementazione del costruttore di ogni classe dovrebbe sapere che i tipi di variabili sono necessari (dalla configurazione di db) e li casterebbe/li userà di conseguenza.

Il passaggio successivo potrebbe essere quello di eliminare davvero l'istruzione selezionata in fabbrica, utilizzando reflection. Dovresti avere il nome della classe come parte dei dati di configurazione dei report nel db (e avere un costruttore comune).

A questo punto, il modo per aggiungere un nuovo report è abbastanza pulito, anche se devi aggiungere una nuova classe ogni volta. Bene. Soddisfa i principi single responsibility e open-closed.

Ora, c'è solo il passaggio finale di rimuovere le classi dall'app, in modo che possano essere aggiunte/modificate al volo. Controlla MEF. Questo è ciò per cui è fatto. Alcune cose che potresti trovare su Internet che probabilmente non dovresti usare sono CodeDom (ottimo quando non c'era nient'altro, ma MEF è meglio) e le funzioni di compilazione-come-servizio che arrivano in .NET 5. MEF è la strada da percorrere

Answer 3

Penso che sia meglio riprogettare questo codice e convertirlo in qualche tabella di database ("Rapporti") per conservare l'elenco di rapporti e ID di ogni rapporto.

Questo è tutto.

Answer 4

di fare questo con un Dictionary<string, string> si dovrebbe semplicemente costruire uno come una cache statica nel tipo contenente

public class Container { 
    private static Dictionary<string, Func<Report>> ReportMap = 
    new Dictionary<string, Func<Report>>(); 
    static Container() { 
    ReportMap["ReportA"] =() => CreateReportAReport("ReportA's Title"); 
    ReportMap["ReportB"] =() => CreateReportBReport("ReportB's Title"); 
    // etc ... 
    } 
} 

Ora che la mappa è costruita è sufficiente fare una ricerca nella funzione invece di un switch

Func<Report> func; 
if (!ReportMap.TryGetValue(Request.QueryString["Report"), out func)) { 
    // Handle it not being present 
    throw new Exception(..); 
} 

Report report = func();