Conceptos DTO y DAO y MVC [closed]

1) ¿Por qué usamos DTO y DAOy cuándo debemos usarlos. estoy desarrollando un GUI Software Java para hacer con la inserción, edición, borrado de datos. Pero me cuesta distinguir entre DTO/DAO y Model, View, Controller (MVC) ¿Estructura? ¿Son similares, que es mejor usar al interactuar con la base de datos a través de Java? GUI.

2) Una cosa que realmente me intriga es si es una buena práctica tener view y Controller en una clase si pensamos en Netbeanspuedes crear GUI Frame Class y agregue componentes como JButton en el marco, haciendo doble clic en el botón le llevará a la actionListener método (Controlador) que parece estar en el cuadro, los datos se mostrarán al usuario (Ver). Así que están en la misma clase. ¿Entonces eso va completamente en contra del concepto o no?

Aquí es de lo que estoy hablando

¿Mala práctica tener vista y controlador en una clase?

DTO es una abreviatura de Objeto de transferencia de datospor 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.
• DTO No se recomienda agregar métodos de lógica empresarial a dichas clases, pero está bien agregar algunos métodos de utilidad.

DAO es una abreviatura de Objeto de acceso a datospor 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 se verían las interfaces DAO y DTO:

interface PersonDTO {
    String getName();
    void setName(String name);
    //.....
}

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

los 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 separadoque contendría la lógica comercial para su marco en una clase separada y enviaría mensajes a este controlador desde los controladores de eventos.
Esto separaría su lógica comercial de la vista.