[Rubajticos]

Cześć, mam pytanie do specjalistów od #spring i #java.

Przykład to dodawania wizyty przez REST. Zauważyłem, że mój kod z dołączonego screena nie działa poprawnie bo w metodzie translateToVisitEntity(...) podczas parsowania DTO na Entity tworzony jest nowy obiekt, który od razu zostaje podpięty do transakcji. W efekcie tego metoda existsByDateTimeAndDoctor znajduje ten obiekt przez co nie da się utworzyć wizyty.

Obszedłem to modyfikując kod w ten sposób, żeby existsByDateTimeAndDoctor było wywołane jeszcze przed parsowaniem DTO(screenshot 2 w komentarzu).

Jak to się powinno robić żeby miało ręce i nogi? Podejrzewam, że usuwanie @Transactional z metod, które coś zapisują do bazy nie jest OK.

#programowanie

[Rubajticos]

@Rubajticos: 2

[Ridicz]

@Rubajticos: Ale po co najpierw tworzysz nowe entity a później sprawdzasz, czy istnieje takie w bazie? Dużo bardziej logicznie i wydajnościowo będzie najpierw sprawdzenie i tworzenie jeśli nie ma takiego w bazie.

[Rubajticos]

@Ridicz: W pierwotnej wersji nie było tego sprawdzania czy wizyta z taką samą datą i lekarzem istnieje już w bazie dlatego tego problemu nie widziałem. To entity tworzę żeby DTO było tylko do komunikacji między gui a serwerem, a całą logikę chciałem oprzeć już na entity. Tyle, że nie ogarnąłem, że dodając @Transactional ten save nic nie robi..

[Rubajticos]

@LazyInitializationException @Ridicz : Czyli jeśli dobrze rozumiem to powinienem rozszerzyć to np w ten sposób?
Na przykładzie Visit:
warstwa persystencji:
- encja mapowana z bazy (@Entity) np. VisitEntity
- JpaRepository ze Spring Data operujące na VisitEntity

warstwa biznesowa:
- obiekt domenowy np. Visit
- drugi poziom repository --> wewnątrz operujący na Repository z warstwy persystencji i mapujący VisitEntity na Visit
- serwis do wykonywania operacji na wizytach np. create, findAll itp. korzystający

[draxgar]

@Rubajticos: W skrócie: Tak. Na warstwie biznesowej, gdzie masz obiekty Visit, gdzie masz serwis, który sprawdzi czy data jest poprawna, a później zapisze wizytę do bazy.
DTO, leci pomiędzy użytkownikiem a twoją aplikacją. Entity nie powinno wychodzić poza serwisy mające styczność z bazą. Najniższa warstwa niech zostanie przy bazie. DTO przy kontrolerach rest. W reszcie aplikacji masz obiekty które mogą być czysto domenowe.

Swoją drogą: IMHO to nie jest 'bad

[Rubajticos]

@draxgar: dzięki za wyjaśnienie, teraz to dużo jaśniejsze :) A co do bad request. Co byś w takiej sytuacji proponował? Coś z serii 200?

[draxgar]

@Rubajticos: Sorry, że słabo z moją responsywnością :)
Jeśli chodzi o kod odpowiedzi to zdania ekspertów są podzielone. Np. Azure zwraca 404, jako że nie ma takiego zasobu (błędne dane wejściowe powodują że się nic nie wyszukuje). Wkurzające, nie powiem, ale ze względów bezpieczeństwa (security) jak najbardziej wskazane: Nie dajemy hintów, potencjalnym włamującym.
Ja bym był za 200 OK i pustą odpowiedzią: czyt. "zrozumiałem twoje zapytanie, a tu masz listę rzeczy

[Rubajticos]

@draxgar: Dzięki za odpowiedź :D