Simple REST web service

Odpowiedz Nowy wątek
2020-03-11 17:00

Rejestracja: 3 tygodnie temu

Ostatnio: 2 dni temu

0

Cześć, jestem młodym studentem IT programującym głównie w Javie.

Napisałem prostą usługę typu REST z wykorzystaniem Spring Boot'a oraz architektury DDD. Projektem jest system zarządzania biblioteką pozwalający na przeglądanie, rezerwację i wypożyczanie książek.

Byłbym wdzięczny o ocenę projektu i stylu kodowania przez bardziej doświadczonych programistów.

Całe repozytorium projektu: library-backend
Bliźniaczy temat na stackexchange: Simple REST web service

wow, fajne readme - danek 2020-03-11 17:02

Pozostało 580 znaków

2020-03-16 22:15

Rejestracja: 5 lat temu

Ostatnio: 54 minuty temu

Lokalizacja: Warszawa

1

Nie ma nic za darmo, jeśli komuś bardzo zależy na JPA i jak napisałeś braku "zakażonych" obiektów, które zawierają kilka adnotacji to można wykorzystać starą konfigurację w xmlu bez użycia adnotacji.

Omg, to wiele nie zmienia, nadal jest to proxy itd

, obiektem proxy staje się dopiero w warstwie aplikacji kiedy do gry rzeczywiście wkracza jpa.

Z tego co wiem wystarczy że jest zwracane z EnityManagera

Nigdzie nie napisałem, że coś jest lepsze lub gorsze, każde rozwiązanie ma swoje wady i zalety jednak uważam, że nie należy stosować jednego lub drugiego rozwiąnia na siłe tam gdzie nie ma takiej potrzeby.

To jakie wady w porówaniu to zalet ma stosowanie niemutowalnych obiektów domenowych? :)

które są mapowane na te znienawidzone (zapewne z wzajemnością) encje JPA.

@Charles_Ray alez po co używać aż takiego słownictwa. Może z tym rakotwórczym trochę przesadziłem :D
JPA może mieć zalety przy operacjach zapisu/aktualizacji/usuwania, ale jak już te JPA stosujesz to trzymaj "przy glebie", np. na poziomie repozytorium bo wyżej moga być problemy ;)

@eziomou
Polecam jeszcze:


Nie pomagam przez PM. Pytania zadaje się na forum.
edytowany 2x, ostatnio: scibi92, 2020-03-16 22:18

Pozostało 580 znaków

2020-03-16 22:49

Rejestracja: 3 tygodnie temu

Ostatnio: 2 dni temu

0

@eziomou
Polecam jeszcze:

Dziękuję, na pewno zobaczę jak zorganizuje trochę czasu.

Nie ma nic za darmo, jeśli komuś bardzo zależy na JPA i jak napisałeś braku "zakażonych" obiektów, które zawierają kilka adnotacji to można wykorzystać starą konfigurację w xmlu bez użycia adnotacji.

Omg, to wiele nie zmienia, nadal jest to proxy itd

, obiektem proxy staje się dopiero w warstwie aplikacji kiedy do gry rzeczywiście wkracza jpa.

Z tego co wiem wystarczy że jest zwracane z EnityManagera

Cała nasza dotychczasowa wymiana zdań dotyczyła warstwy domeny, więc po raz kolejny piszę, że poza adnotacjami, JPA nie ma żadnego udziału w warstwie domeny w podejściu DDD, również EntityManager.

Nigdzie nie napisałem, że coś jest lepsze lub gorsze, każde rozwiązanie ma swoje wady i zalety jednak uważam, że nie należy stosować jednego lub drugiego rozwiąnia na siłe tam gdzie nie ma takiej potrzeby.

To jakie wady w porówaniu to zalet ma stosowanie niemutowalnych obiektów domenowych? :)

Pierwsze co mi przychodzi na myśl, o czym już wcześniej pisałem to konieczność zapewniania niezmienności w przypadku gdy jest to kompletnie zbędne.
Dodatkowo potencjalne wady dobrze wytłuszczyłeś w swoim artykule.

edytowany 1x, ostatnio: eziomou, 2020-03-16 23:01

Pozostało 580 znaków

2020-03-17 00:06

Rejestracja: 5 lat temu

Ostatnio: 54 minuty temu

Lokalizacja: Warszawa

1

więc po raz kolejny piszę, że poza adnotacjami, JPA nie ma żadnego udziału w warstwie domeny w podejściu DDD, również EntityManager.

Czyli ma a nie powinno mieć. Wystarczy że wywalisz JPA z mavena i nagle Twoja domena się kompiluje, a tak nie powinno być, no chyba że zakładasz pisanie CRUDa, tylko wtedy nie stosujesz takich architektur jak DDD. Może trochę spędzisz czasu w życiu z JPA to wtedy zrozumiesz :)

Pierwsze co mi przychodzi na myśl, o czym już wcześniej pisałem to konieczność zapewniania niezmienności w przypadku gdy jest to kompletnie zbędne.

Musze Cię zmartwić, zasadniczo jest odwrotnie. Obiekt powinien być niemutowalny chyba że istnieje jakaś racjonalna przyczyna żeby był mutowalny. Chyba że nie lubisz korzystać ze współbieżności, albo lubisz "brudne funkcje" a przez to psują jakość kodu. Przekazujesz argument i nie wiesz czy ktoś go nie będzie chcial zmienić więc ryzykujesz. Może lubisz długo debugować i wstawiać breakpointy co 2 linijki żeby sprawdzić co się stało.

W każdym razie pytałeś o zdanie bardziej doświadczonych programistów to się odezwałem.
PS
Polecam ksiązke "Clean Architecture"


Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

2020-03-17 01:23

Rejestracja: 3 tygodnie temu

Ostatnio: 2 dni temu

0

@scibi92:

więc po raz kolejny piszę, że poza adnotacjami, JPA nie ma żadnego udziału w warstwie domeny w podejściu DDD, również EntityManager.

Czyli ma a nie powinno mieć. Wystarczy że wywalisz JPA z mavena i nagle Twoja domena się kompiluje, a tak nie powinno być...

Jasne, zgadzam się, do tej pory rozmawialiśmy o wpływie JPA na logikę.

Mógłbyś mi jeszcze napisać co Twoim zdaniem jest racjonalną przyczyną dla mutowalności oraz czy według Ciebie każda klasa niemutowalna lub metoda, która zmienia stan instancji klasy do której należy jest kodem złej jakości? Czy brak wymogu dotyczącego współbieżności dla danej klasy lub założenie projektowe dotyczące precyzyjnego odwzorowania modelowanej dziedziny (DDD) jest dla Ciebie wystarczającą przesłanką o mutowalności?

W każdym razie pytałeś o zdanie bardziej doświadczonych programistów to się odezwałem.

Dzięki za opinię!

edytowany 4x, ostatnio: eziomou, 2020-03-17 02:26

Pozostało 580 znaków

2020-03-17 20:56

Rejestracja: 5 lat temu

Ostatnio: 54 minuty temu

Lokalizacja: Warszawa

0

Mógłbyś mi jeszcze napisać co Twoim zdaniem jest racjonalną przyczyną dla mutowalności

Naturalność lub wydajność.
Trudno mi sobie wyobrazić niemutowalne okienko w Swingu, czy niemutowalny strumień I/O.

? Czy brak wymogu dotyczącego współbieżności dla danej klasy

Nie,

precyzyjnego odwzorowania modelowanej dziedziny (DDD) jest dla Ciebie wystarczającą przesłanką o mutowalnośc

Niemutowalność jak najbardziej idzie w parze moim zdaniem z logiką biznesową, i dlatego dla mnie naturalne bardziej byłoby tworzenie logiki biznesowej z obiektami niemutowalnymi.
Przykłady gdzie widze sens dla mutowalności:
1)Rzeczy związane z I/O
2)Niektóre narządzia do wielowątkowści. Np. ciężko mi sobie wyobrazić niemutowalny ExecutorService albo CountDownLatch. Nie zmienia to faktu że nawet tam ogranicza się mutowalność do minimum.
3)GUI - dla mnie mutowalne okienko jest bardziej racjonalne niż niemutowalne
4)Cachowanie danych (tam często jest HashMapa wykorzystywana) w samej Javie
5)Kiedy znaczenie ma wydajność, np. low-latency - wtedy nie chcesz wywoływać zbyt często GC, no i też często dochodze rzeczy typu operacje na bajtach, off-heap memory itp


Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

Odpowiedz

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