He visto varios argumentos contra el DAO que se llama directamente desde la clase Controlador y también el DAO desde la clase Modelo. De hecho, personalmente siento que si seguimos el patrón MVC, el controlador no debería acoplarse con el DAO, sino con la clase Modelo debería invocar el DAO desde dentro y el controlador debería invocar la clase de modelo. Por eso, podemos desacoplar la clase de modelo aparte de una aplicación web y exponer las funcionalidades de varias maneras, como para que un servicio REST use nuestra clase de modelo.
Si escribimos la invocación DAO en el controlador, no sería posible que un servicio REST reutilice la funcionalidad ¿verdad? He resumido los dos enfoques a continuación.
Enfoque n. ° 1
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
new CustomerDAO().save(customer);
}
}Enfoque n. ° 2
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
customer.save(customer);
}
}
public class Customer {
...........
private void save(Customer customer){
new CustomerDAO().save(customer);
}
}Nota -
Esto es lo que es una definición de Modelo:
Modelo: el modelo administra el comportamiento y los datos del dominio de la aplicación, responde a las solicitudes de información sobre su estado (generalmente desde la vista) y responde a las instrucciones para cambiar el estado (generalmente desde el controlador).
En los sistemas controlados por eventos, el modelo notifica a los observadores (generalmente vistas) cuando la información cambia para que puedan reaccionar.
Necesitaría una opinión experta sobre esto porque encuentro que muchos usan # 1 o # 2, ¿cuál es?
Respuestas:
En mi opinión, debe distinguir entre el patrón MVC y la arquitectura de 3 niveles. Para resumir:
Arquitectura de 3 niveles:
El patrón MVC tiene lugar en el nivel de presentación de la arquitectura anterior (para una aplicación web):
Ciclo de vida de una solicitud HTTP típica :
fuente
De la capa modelo.
Para ser más precisos: de los servicios, que están contenidos en la capa del modelo , porque gobiernan la interacción entre los objetos de dominio y las abstracciones lógicas de almacenamiento.
El controlador solo debe ser responsable de cambiar el estado de la capa del modelo. Los DAO son parte del mecanismo de persistencia. Esto constituye una parte de la lógica de negocios y aplicaciones del dominio. Si comienza a interactuar con los DAO en el controlador, estaría filtrando la lógica del dominio en la capa de presentación .
fuente
No estoy seguro de lo que exige el patrón MVC oficial, pero normalmente me gusta tener una capa de "servicio" entre los controladores y los DAO. El controlador extrae los datos de la solicitud y los pasa a la clase de servicio adecuada. La clase de servicio es responsable de llamar a uno o más DAO que devuelven clase (s) de modelo. Esas clases de modelo se envían de vuelta al controlador para que se envíen a la capa de vista. Poner la capa de servicio en ayuda con la reutilización ya que múltiples controladores pueden hacer uso de los mismos métodos de capa de servicio.
fuente