Koncepcje DTO i DAO oraz MVC [zamknięte]

1) Dlaczego używamy DTOi DAO, a kiedy powinniśmy z nich korzystać. Zajmuję się tworzeniem GUIoprogramowania Java do czynienia z wstawianie, edytowanie, usuwanie danych. Ale ja jestem stara się odróżnić DTO/DAOi Model, View, Controller(MVC) Struktura? Czy są podobne, co jest lepsze w przypadku interakcji z bazą danych za pośrednictwem języka Java GUI.

2) Jedno jestem bardzo ciekaw, czy jest to dobra praktyka, aby mieć viewi Controllerw jednej klasie. Jeśli się nad tym zastanowić Netbeans, możesz stworzyć GUIklasę ramki i dodać komponenty jak JButtonna ramkę, dwukrotne kliknięcie przycisku przeniesie Cię do actionListenermetody (Kontroler), która wydaje się być w ramce, w której dane mają być wyświetlane użytkownikowi (Widok) . Więc są w tej samej klasie. Czy jest to więc całkowicie sprzeczne z koncepcją, czy nie?

Oto o czym mówię

zła praktyka posiadania widoku i kontrolera w jednej klasie?

DTOjest skrótem od Data Transfer Object , więc służy do przesyłania danych między klasami i modułami aplikacji.

• DTO powinien zawierać tylko prywatne pola dla danych, metod pobierających, ustawiających i konstruktorów.
• DTO nie zaleca się dodawania metod logiki biznesowej do takich klas, ale można dodać niektóre metody util.

DAOjest skrótem od Data Access Object , więc powinien zawierać logikę pobierania, zapisywania i aktualizowania danych w Twoim magazynie danych (baza danych, system plików, cokolwiek).

Oto przykład, jak wyglądałyby interfejsy DAO i DTO:

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

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

MVCJest szerszy wzór. Model DTO / DAO byłby Twoim modelem we wzorcu MVC.
Informuje, jak zorganizować całą aplikację, a nie tylko część odpowiedzialną za pobieranie danych.

Jeśli chodzi o drugie pytanie, jeśli masz małą aplikację to jest całkowicie OK, jednak jeśli chcesz podążać za wzorcem MVC, lepiej mieć osobny kontroler , który będzie zawierał logikę biznesową dla Twojej ramki w osobnej klasie i wysyłaj komunikaty do tego kontrolera z programów obsługi zdarzeń.
To oddzieliłoby logikę biznesową od widoku.