Gdzie robić konwersje, DTO

Siema
Pracowałem trochę w Embedded, chciałbym się nauczyć robić porządny backend do własnych projektów.
Wybrałem sobie Javowy Spring i odpaliłem mały kursik.

Załóżmy, że mam taką encję:

@Entity
@Table(name = "Users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String login;
    private String password;
    private String email;
    private String rank;
    private Set<Order> orders;

    User() {}

    // + getery, setery

• do tego Repository, Service, Controller (na razie bez walidacji, to wleci zaraz po tym).

Przy tworzeniu usera na froncie, podaję sobie: login, hasło i email i wysyłam. (wiadomo, że na starcie nie ma żadnych zamówień, więc to jest puste, a ranga jest domyślna).
Z kolei w moim API chciałbym udostępniać tylko login, email oraz rangę. Bez zamówień i hasła :)

Aby nie wysyłać tego, czego nie chcę i żeby nie wysyłać JSONem pustych pól, to zrobiłem sobie dodatkowo klasy UserWriteModel (to jest wysyłane przez front) i UserReadModel (to jest wysyłane przez mój kontroler na żądanie GET, oba zawierają tylko te pola, które chciałem (napisałem wyżej) <tak robił gościu w kursie>.

Pytania:

1. Czy to są właśnie te DTO (Data Transfer Object)? Gościu w kursie nic o tym DTO nie wspominał, a spotkałem się wiele razy z tym terminem.
2. Nowego usera tworzę w serwisie. Gdzie z kolei robić mapowanie z Usera na te UserReadModel? Też w serwisie?
3. Czy te nazwy są w ogóle sensowne (UserWriteModel, UserReadModel)? Wydają się ok

Ogólnie ten kurs to szajs
PS: ten przykład z userem i udostępnianiem może jest bezsensowny, ale taki wydaje mi się najłatwiejszy, chodzi mi tylko o to, żeby ktoś potwierdził z tym DTO

Gdzie można coś poczytać o dobrej architekturze aplikacji webowych

Zrób założenie że do serwisów przyjmujesz w argumencie / zwracasz jako rezultat, klasy które nie są encjami i samo Ci się wyklaruje.

Odpowiedzi

1. DTO to klasa transferowa służąca jedynie jako paczka na dane.
2. Tak
3. Ja bym robił UserWriteDTO lub UserReadDto

robić porządny backend

Hibernate

Repository, Service, Controller

pick one

Gościu w kursie nic o tym DTO nie wspominał

Ta, bo to pewnie klasyczny kurs encja na twarz i pchasz ;) Dla generic cruda pewnie się sprawdzi. W prawdziwym życiu to są zupełnie osobne modele:

• dane które ktoś wysyła do systemu (przychodzące jako jakieś DTO)
• dane które system wystawia na świat (wychodzące jako jakieś DTO, często inne niż te powyżej)
• dane które system przetwarza "wewnętrznie", to jest model domenowy i często łączy w sobie dane z różnych źródeł plus logikę działania na nich
• dane które są przez system zapisywane w sposób trwały (model bazodanowy)

@Burdzi0: JPA to jedna wielka cieknąca abstrakcja którą żeby dobrze zrozumieć musisz przeczytać i zapamiętać książki wielkości biblii. Jak jej nie ogarniesz to albo wsadzasz do pamięci cały graf encji gdzie potrzebujesz jednego pola, albo masz jakiś N+1.