Problema identificado:
En el diseño original, la capa de presentación (específicamente la interfaz gráfica Pnl_Content_Venta) estaba fuertemente acoplada a la capa de acceso a datos. Aunque la transacción principal ya estaba agrupada en el método realizarVenta del VentaGestionDao, la vista aún debía encargarse de preparar, desempaquetar y gestionar listas complejas de detalles, y coordinar los parámetros exactos de la base de datos para poder registrar la operación. Esto viola el principio de responsabilidad única y expone la complejidad del modelo de datos a la interfaz de usuario.
Solución propuesta:
Se implementó el patrón de diseño estructural Facade (Fachada) para crear una interfaz simplificada de comunicación entre la vista y la lógica de base de datos.
-
Se creó la clase VentaFacade dentro del paquete de controladores.
-
Se programó el método procesarVentaFachada, el cual recibe únicamente el objeto Cliente y el objeto compuesto BoletaCompleta (generado por el patrón Builder).
-
Se limpió la clase Pnl_Content_Venta, eliminando la importación directa de los DAOs y reduciendo el evento de guardado a una simple llamada booleana hacia la Fachada.
Consecuencias e implicaciones del rediseño:
-
Reducción drástica de la complejidad en la capa de presentación (Vista). Alto desacoplamiento: si en el futuro cambian las tablas o la firma del método en el DAO, la vista no sufrirá ningún cambio, solo se actualizará la Fachada. Código mucho más legible y fácil de mantener.
-
Se introduce una nueva capa de indirección (la clase Facade) que incrementa ligeramente la cantidad de archivos del proyecto, obligando a que el flujo de datos pase por un intermediario antes de llegar al DAO.
Problema identificado:
En el diseño original, la capa de presentación (específicamente la interfaz gráfica Pnl_Content_Venta) estaba fuertemente acoplada a la capa de acceso a datos. Aunque la transacción principal ya estaba agrupada en el método realizarVenta del VentaGestionDao, la vista aún debía encargarse de preparar, desempaquetar y gestionar listas complejas de detalles, y coordinar los parámetros exactos de la base de datos para poder registrar la operación. Esto viola el principio de responsabilidad única y expone la complejidad del modelo de datos a la interfaz de usuario.
Solución propuesta:
Se implementó el patrón de diseño estructural Facade (Fachada) para crear una interfaz simplificada de comunicación entre la vista y la lógica de base de datos.
Se creó la clase VentaFacade dentro del paquete de controladores.
Se programó el método procesarVentaFachada, el cual recibe únicamente el objeto Cliente y el objeto compuesto BoletaCompleta (generado por el patrón Builder).
Se limpió la clase Pnl_Content_Venta, eliminando la importación directa de los DAOs y reduciendo el evento de guardado a una simple llamada booleana hacia la Fachada.
Consecuencias e implicaciones del rediseño:
Reducción drástica de la complejidad en la capa de presentación (Vista). Alto desacoplamiento: si en el futuro cambian las tablas o la firma del método en el DAO, la vista no sufrirá ningún cambio, solo se actualizará la Fachada. Código mucho más legible y fácil de mantener.
Se introduce una nueva capa de indirección (la clase Facade) que incrementa ligeramente la cantidad de archivos del proyecto, obligando a que el flujo de datos pase por un intermediario antes de llegar al DAO.