Gdzie robić konwersje, DTO

0

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

0

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
1

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)
1

@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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0