java - patron - Conceptos de DTO y DAO y MVC

patron vo

Question

1) ¿Por qué usamos DTO y DAO , y cuándo deberíamos usarlos? Estoy desarrollando un software GUI Java para insertar, editar y eliminar datos. Pero estoy luchando para distinguir entre DTO/DAO y Model , View , Controller (MVC) Structure? ¿Son similares, que es mejor usar cuando se interactúa con la base de datos a través de la GUI Java?

2) Una cosa que realmente me llama la view es si es una buena práctica tener view y Controller en una clase. Si pensamos en Netbeans , puede crear una clase de estructura de GUI y agregar componentes como JButton en el marco, al hacer doble clic en el botón, accederá al método actionListener (controlador) que parece estar en el marco en el que se mostrarán los datos al usuario (Ver). Entonces están en la misma clase. ¿Está yendo completamente en contra del concepto entonces o no?

<a href="http://www.youtube.com/watch?v=Iwwznm9XSME">Here is what Im talking about</a>

mala práctica para tener vista y controlador en una clase?

Answer 1

DTO es una abreviatura de Objeto de transferencia de datos, por lo que se utiliza para transferir los datos entre clases y módulos de su aplicación. DTO solo debe contener campos privados para sus datos, getters, setters y constructores. No se recomienda agregar métodos de lógica de negocios a dichas clases, pero está bien agregar algunos métodos de utilidad.

DAO es una abreviatura de Objeto de acceso a datos, por lo que debe encapsular la lógica para recuperar, guardar y actualizar datos en su almacenamiento de datos (una base de datos, un sistema de archivos, lo que sea). Aquí hay un ejemplo de cómo serían las interfaces DAO y DTO:

interface PersonDTO {
String getName();
void setName(String name);
//.....
}
interface PersonDAO {
PersonDTO findById(long id);
void save(PersonDTO person);
//.....
}

El MVC es un patrón más amplio. El DTO / DAO sería su modelo en el patrón MVC. Le dice cómo organizar toda la aplicación, no solo la parte responsable de la recuperación de datos.

En cuanto a la segunda pregunta, si tiene una aplicación pequeña, está completamente bien, sin embargo, si desea seguir el patrón MVC, sería mejor tener un controlador por separado, que contendría la lógica de negocios para su marco en una clase separada y enviar mensajes a este controlador desde los controladores de eventos. Esto separaría su lógica comercial de la vista.