Efectivamente con la solución que se ha planteado se está obligando a que si tienes 200 DAO, necesites un switch con 200 condiciones.

A priori puede parecer descabellado, pero ten en cuenta que se está gestionando de forma interna y transparente a los clientes que llaman a la capa de negocio. Puede que necesites un switch con 200 casos, pero para acceder a esos 200 objetos de negocio expones hacia fuera un único servicio con cuatro o cinco métodos que permiten hacer las operaciones básicas para cualquiera de los 200 DAO.

De ahí la gracia de todo este sistema, que sea estupendo para preparar por ejemplo una típica aplicación de mantenimiento.

Eso sí, como bien dices, y centrándonos únicamente en el “problema” del switch, el manejo de la factoría es mejorable, déjame pensar en algo a ver qué se me ocurre, puede que encontremos una manera de hacer que esta parte del código aumente en mantenibilidad y legibilidad.

Cualquier aportación al respecto será bienvenida

Saludos!

Miguel.

“Como véis esto sería la leche ya que cualquier llamada al servicio sería capaz de ejecutar la acción independientemente del DTO que le llegue…

Por aquí dejo el código de la factoría, que como véis, según el DTO que recibe, retorna el DAO correspondiente.”

Pero que hay de esta parte si tengo mucho objetos DAO que mantener 100 o 200, aqui tendria un case o un if de 200 posibilidades? ¿Como se podria manejar esto?

public static IDAO GetDAO(IDTO dto)
{
if (dto is CocheDTO)
{
return CocheDAO.GetInstance();
}
else if (dto is MarcaDTO)
{
return MarcaDAO.GetInstance();
}
throw new Exception(”no existe este dto”);
}