Jedziemy dalej:
- w
UserController
brakuje ci <>
przy ResponseEntity. Tego typu błędy wyłapuje IntelliJ, nie rozumiem czemu w ogóle to masz
- A tak w sumie, to nie potrzebujesz ResponseEntity, tylko możesz zwrócić
User
i zaadnotować to @ResponseStatus(201)
. To samo w PostController
Racja, tak będzie lepiej
- Czemu pola
User
nie są prywatne? Czemu obiekt nie jest immutable?
Przeoczenie, zapomniałem zmienić gdy usunąłem odnotację @Value
- Twój UserEntity tylko udaje immutable, bo ma w polu mutable Set
Ok, chciałem mieć łatwiejszy sposób aktualizowania userów, ale może lepiej nadpisywać obiekty przy aktualizacji zamiast mutować
- Mieszasz konfigurację za pomocą klas
@Configuration
i adnotacji nad klasami. Zdecyduj się na jedno rozwiązanie, żeby było konsekwentnie
Tego nie rozumiem, @Configuration jest ze springa, a adnotacje nad klasami z lomboka, nie używam annotation based configuration nigdzie.
- Po co metoda mapUserEntityToUser zwraca funkcje, zamiast po prostu przyjąć UserEntity w parametrze? KISS
- Chopuj buildery
Co to znaczy?
- W InMemoryUsersRepository#trackUser user i userEntity to to samo =P. Zrobisz dwa razy fetcha na mapie
- Brzydko nazywasz paczki. Repozytorium nie należy do domeny biznesowej. Encje też. Natomiast obiekt biznesowy (Post, User) już tak. Tylko przypadkiem jest on jednocześnie DTOsem.
Wzorowałem się na przykładzie Jakuba :)
- retrievePostsByUserId może wzrócić nulla i wtedy getPostsByUserIds walnie NPE
- Nie iniektujesz poprawnego LocalDateTimeProvider w postsRepository
Dzięki, przeoczenie.
- Osobiście przeniósłbym metodę getUser z PostFacade do UserFacade (tą która zwraca czystego Usera). I schował UserNotFoundException do paczki users. I schował ExceptionHandlerController (de facto UserExceptionHandlerController) do paczki users. Masz wtedy całą obsługę użytkowników zamkniętą w jednej paczce