¿Reemplazo para interruptor grande?

Question

tengo una página llamada "ReportController.aspx", cuyo propósito es crear una instancia de un informe (clase) en base a los parámetros de cadena de consulta

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

Básicamente, cada vez que se necesita un nuevo informe que habrá de añadir esta sobrecarga un caso y agregando un método. Esta declaración de cambio podría ser muy larga. Leí que es posible usar un diccionario para mapear un informe a?. ¿Cómo se vería esto usando un diccionario (suponiendo que esta sea una mejor manera).

Además, el método CreateReportXReport pasa básicamente un grupo de valores adicionales de QueryString al constructor de la clase de informe (cada clase de informe tiene un constructor diferente).

Answer 1

Suponiendo que todos los informes implementan IReport, puede hacerlo utilizando Func<IReport>, así:

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

A continuación, puede reemplazar el interruptor con este código:

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

Answer 2

No hay manera alrededor de tener escribir la nueva información en alguna parte; la clave es sacarlo del código, para evitar recompilar y volver a implementarlo para un cambio tan trivial.

Algunas buenas opciones son enumerar estos valores en un archivo de configuración XML, o mejor aún, en su base de datos.

Es probable que desee completar un diccionario con esta información, cualquiera que sea la fuente. Esta voluntad:

• Que sea fácil de almacenar en caché
• Hacer para la limpieza, código rápido

Cuando llega el momento de sacar sus datos de configuración en código, que le agregan elementos al diccionario de este modo:

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

este ejemplo se supone que consiguen sus datos como entidad objeto de algún tipo, y el uso de una fábrica que utilizaría un strategy pattern para su código que crea repor ts. Hay un montón de maneras en que podrías estar haciendo esto por supuesto.

Supongo que los informes son demasiado extensos, variados y de naturaleza diferente que no se puede simplemente poner sql y diseñar bloque de construcción en la base de datos?

Editar basado en los comentarios de OP:

Ah, Gotcha. Bueno, no sé cuánto tiempo tienes, pero por mucho que introduzcas todo en algún tipo de factory, tienes mejores opciones que tendrás más adelante. Voy a darle algunos pensamientos que con suerte ayudarán, de cosas similares que hice. Cada paso es una mejora en sí mismo, pero también un pequeño paso para realmente separar su lógica de informes de este código de shell. Además, puedo ver que ya sabes lo que estás haciendo y estoy seguro de que sé algo de lo que voy a decir a continuación, pero no sé lo que sabes, y será útil para otros.

Primero, extraiga toda la información del código a db (si no lo ha hecho), y agregará más campos de base de datos (y una tabla o dos) a medida que mejore su configuración.

Puede que ya lo sepas, pero lo mencionaré para otros, para ver el patrón de estrategia que menciono arriba. Puede hacer que la lógica personalizada de cada "función de informe" esté realmente en el constructor de sus diversas clases de estrategia. Todos heredarían de su ReportGenerator base (o lucirían una interfaz IReportGenerator común). Pueden y deben compartir el mismo constructor; los parámetros de informe variables se manejarían mediante un parámetro de tipo diccionario. La implementación del constructor de cada clase sabría los tipos de las variables que se necesitan (desde la configuración de db), y las usaría/usaría en consecuencia.

El siguiente paso podría ser deshacerse de su declaración seleccionada en su fábrica, usando reflection. Debería tener el nombre de la clase como parte de los datos de configuración de informes en el archivo db (y tener un constructor común).

En este punto, la forma de agregar un nuevo informe es bastante clara, aunque debe agregar una nueva clase cada vez. Asi de bueno. Cumple con los principios single responsibility y open-closed.

Ahora, solo queda el paso final de que elimina las clases de su aplicación, por lo que se pueden agregar o editar sobre la marcha. Consulte MEF. Esto es para lo que está hecho. Algunas cosas que puede encontrar en Internet que probablemente no deberían ser son CodeDom (excelente cuando no había nada más, pero MEF es mejor) y las características de compilación como servicio que vienen en .NET 5. MEF es el camino a seguir.

Answer 3

Creo que es mejor volver a diseñar este código y convertirlo en una tabla de base de datos ("Informes") para mantener allí la lista de informes y el ID de cada informe.

Eso es todo.

Answer 4

Para hacer esto con un Dictionary<string, string> sólo tendría que construir uno como un caché estática en el tipo que contiene

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 ... 
    } 
} 

Ahora que el mapa se construye sólo tiene que hacer una búsqueda en la función en lugar de una switch

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

Report report = func();