1. nazewnictwo - czy nazywacie wasze modele, np StudentDto, tylko, gdy są używane do mapowania w kierunku encja -> dto (jako response), czy, gdy dotyczy do requestów, request -> encja 2. jeśli NIE WSZYSTKIE pola dla studenta są aktualizowane to czy, utworzenie modelu StudentUpdateDto jest dobrą praktyką czy powinienem wysłać poprzez PUT, tylko te parametry, które chcę zaaktualizować? 3. W niektórych przypadkach, używany jest ten sam model dla zapytania jak i dla odpowiedzi do API, np. przy tworzeniu studenta, używany jest, StudentDto w obu kierunkach. Zauważyłem, że zawiera on pole ID. Pytanie, czy w przypadku zapytań do API, gdy użytkownik jeszcze nie istnieje i ktoś wpisze id w tym zapytaniu. Czy to nie sprawi, że zapiszemy użytkownika z kluczem głównym o podanym przez kogoś ID. Wydaje mi się, że to baza powinna zadbać generowanie kolejnych ID.
@AnonimoweMirkoWyznania: 1. Nie każdy request = 1:1 encja. Widziałem różne podejścia, np. takie same nazwy klas ale inne pakiety. 3. nie powinieneś mieć id wysyłanego przez usera.
@AnonimoweMirkoWyznania: 1. Obecnie najważniejsza jest konsekwencja. Najczęściej dla zapytań tworzy się obiekty StudentRequest i ich odpowiedzi StudentResponse, a DTO używa wewnątrz. Nie ma jednej odgórnej konwencji. Najczęściej ustala się to raz w projekcie i pilnuje własnych wytycznych na Code Review. 2. W PUTcie powinieneś wysyłać cały obiekt do zastępowania. Jeśli tworzysz endpoint do updatowania tylko części pól odpowiedniejsza jest metoda PATCH, jednak dobrego, zgodnego z hateoasem PATCHA ciężko porządnie napisać. https://clockworkjava.pl/2021/02/rest-api-post-vs-put-vs-patch/
1. nie umieszczam DTO w nazwie klasy tylko w pakiecie cośtam.dto.Student i nie trzymam się ściśle tych zasad, jak mam pośrednika to nazywam to dto, z resztą ostatnio coraz mniej widzę kodu używającego ORMów (chyba moda się zmienia :) ) więc encji nie ma, a DTO dalej używamy 2. niby można, w praktyce nigdy tego nie robiłem bo nie potrzebowałem 3. API nie powinno nic wiedzieć o id bazodanowym, nieważne
tutaj jest ten temat wyczerpany wystarczająco, powiedziałbym że aż zanadto, a jeżeli chodzi o używanie DTO w nazwie to używam o plusach kiedyś opowiem....
agile-hejter: 1. W projektach raczej spotkasz się z nazewnictwem *DTO - dla mnie trochę przeżytek, coś jak w implementacji interfejsu *Impl 2. W takich wypadku powinieneś użyć PATCH - aktualizuje wybrane części zasobu, PUT podmienia zasób :) 3. W POST nie powinieneś mieć opcji wysłania ID, zdecydowanie IDki powinny być generowane na backendzie, co najfajniejsze nie musisz zwracać w danych resource-a w ogóle ID -> możesz użyć HATEOAS https://spring.io/projects/spring-hateoas#overview i mieć
agile-hejter: @jaca_66 to już napisz o tych benefitach DTO w nazwie, tak na szybko co udało mi się wymyślić: + szybko w IDE widać która klasa do czego + można rezać refleksją po klasach i używać tego jako patternu (benefit hehe, refleksja hehe), pakietu też można ;d kontrargumenty: * jak generujesz te DTOsy jakimś pluginem np z openapi to by default tak Ci klas nie utworzy (chyba że w yamlu czy
Nie wiem co to za posmiewisko na wykopie z osób które idą na miesięczne przeszkolenie wojskowe i składają przysięgę. Jakby była wojna to i tak każdy z nas będzie miał gówno do gadania xD #wojsko #ukraina #wojna
Hej, mam kilka pytań odnośnie DTO w springu.
1. nazewnictwo - czy nazywacie wasze modele, np StudentDto, tylko, gdy są używane do mapowania w kierunku encja -> dto (jako response), czy, gdy dotyczy do requestów, request -> encja
2. jeśli NIE WSZYSTKIE pola dla studenta są aktualizowane to czy, utworzenie modelu StudentUpdateDto jest dobrą praktyką czy powinienem wysłać poprzez PUT, tylko te parametry, które chcę zaaktualizować?
3. W niektórych przypadkach, używany jest ten sam model dla zapytania jak i dla odpowiedzi do API, np. przy tworzeniu studenta, używany jest, StudentDto w obu kierunkach. Zauważyłem, że zawiera on pole ID. Pytanie, czy w przypadku zapytań do API, gdy użytkownik jeszcze nie istnieje i ktoś wpisze id w tym zapytaniu. Czy to nie sprawi, że zapiszemy użytkownika z kluczem głównym o podanym przez kogoś ID. Wydaje mi się, że to baza powinna zadbać generowanie kolejnych ID.
Dzięki za odpowiedzi
#programowanie #naukaprogramowania #programista15k #spring #java
Kliknij tutaj, aby odpowiedzieć w tym wątku anonimowo
Kliknij tutaj, aby wysłać OPowi anonimową wiadomość prywatną
ID: #61ec55a4f7bdff000a930ef9
Post dodany za pomocą skryptu AnonimoweMirkoWyznania ( https://mirkowyznania.eu ) Zaakceptował: LeVentLeCri
Wesprzyj projekt
1. Nie każdy request = 1:1 encja. Widziałem różne podejścia, np. takie same nazwy klas ale inne pakiety.
3. nie powinieneś mieć id wysyłanego przez usera.
1. Obecnie najważniejsza jest konsekwencja. Najczęściej dla zapytań tworzy się obiekty StudentRequest i ich odpowiedzi StudentResponse, a DTO używa wewnątrz. Nie ma jednej odgórnej konwencji. Najczęściej ustala się to raz w projekcie i pilnuje własnych wytycznych na Code Review.
2. W PUTcie powinieneś wysyłać cały obiekt do zastępowania. Jeśli tworzysz endpoint do updatowania tylko części pól odpowiedniejsza jest metoda PATCH, jednak dobrego, zgodnego z hateoasem PATCHA ciężko porządnie napisać. https://clockworkjava.pl/2021/02/rest-api-post-vs-put-vs-patch/
1. nie umieszczam DTO w nazwie klasy tylko w pakiecie cośtam.dto.Student i nie trzymam się ściśle tych zasad, jak mam pośrednika to nazywam to dto, z resztą ostatnio coraz mniej widzę kodu używającego ORMów (chyba moda się zmienia :) ) więc encji nie ma, a DTO dalej używamy
2. niby można, w praktyce nigdy tego nie robiłem bo nie potrzebowałem
3. API nie powinno nic wiedzieć o id bazodanowym, nieważne
tutaj jest ten temat wyczerpany wystarczająco, powiedziałbym że aż zanadto, a jeżeli chodzi o używanie DTO w nazwie to używam o plusach kiedyś opowiem....
https://stackoverflow.com/questions/1051182/what-is-a-data-transfer-object-dto
2. W takich wypadku powinieneś użyć PATCH - aktualizuje wybrane części zasobu, PUT podmienia zasób :)
3. W POST nie powinieneś mieć opcji wysłania ID, zdecydowanie IDki powinny być generowane na backendzie, co najfajniejsze nie musisz zwracać w danych resource-a w ogóle ID -> możesz użyć HATEOAS https://spring.io/projects/spring-hateoas#overview i mieć
@AnonimoweMirkoWyznania: XDDDDDDD
+ szybko w IDE widać która klasa do czego
+ można rezać refleksją po klasach i używać tego jako patternu (benefit hehe, refleksja hehe), pakietu też można ;d
kontrargumenty:
* jak generujesz te DTOsy jakimś pluginem np z openapi to by default tak Ci klas nie utworzy (chyba że w yamlu czy