DTO and DAO and MVC concepts

Question

1) Why do we use DTO and DAO , and when should we use them. I am developing software with a Java GUI for inserting, editing, deleting data. But am I struggling to distinguish between DTO/DAO and the Model , View , Controller (MVC) structure? They are similar, which is better to use when interacting with the database through the Java GUI .

2) One thing that really interests me is whether it is good practice to have view and Controller in the same class. If we think about Netbeans , you can create a Frame Class GUI and add components like JButton to the frame. Double-clicking on the button will take you to the actionListener (Controller) method, which seems to be in the frame in which the data should be displayed in the User (View). So they are in the same class. Does this completely contradict the concept or not?

That's what i'm talking about

bad practice to have vision and controller in the same class?

Answer 1

DTO is short for Data Transfer Object , which is why it is used to transfer data between classes and modules of your application.

• DTO should contain only private fields for your data, methods of obtaining, installation and constructors.
• DTO not recommended to add business logic methods to such classes, but you can add some util methods.

DAO is an abbreviation for Object Access Object , so it must contain logic for retrieving, saving, and updating data in your data warehouse (database, file system, etc.).

Here is an example of what the DAO and DTO interfaces will look like:

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

MVC is a broader model. DTO / DAO will be your model in the MVC pattern.
It tells how to organize the whole application, and not just the part that is responsible for finding data.

As for the second question, if you have a small application, everything is fine, however, if you want to follow the MVC pattern, it would be better to have a separate controller that would contain the business logic for your frame in a separate class. and send messages to this controller from event handlers.
This will separate your business logic from presentation.