clean architecture JPA vs JDBC

1

Co jest lepszym wyborem JPA czy JDBC w przypadku gdy chce zachować obiekty domeny zupełnie nieświadome warstwy persystencji? Używając JPA mógłbym skorzystać z XML'a do mapowania jednak JPA nadal wprowadza wymagania takie jak bezargumentowy konstruktor co infekuje obiektu domeny i w przypadku klas z polami niezmiennymi może być problematyczne. Mógłbym za każdym razem tworzyć oddzielny model dla warstwy persystencji jednak wprowadza to sporo dodatkowej pracy i jednocześnie pozbywam się zalet ORM takich jak lazy loading i śledzenie zmian. Czy jest sens w takiej sytuacji używać JPA kiedy chce zachować 100%-ową niezależność warstwy domeny? Czy lekkie uzależnienie warstwy domeny od persysencji jest lepszym wyborem niż całkowita rezygnacja z ORM? W większych projektach używanie samego JDBC (try, catch) wydaje się niezbyt rozsądne.

1
eziomou napisał(a):

pozbywam się zalet ORM takich jak lazy loading

lazy loading z bazy danych nie jest zaletą tylko drogą na skróty (jak całe JPA)

W większych projektach używanie samego JDBC (try, catch) wydaje się niezbyt rozsądne.

Jest jeszcze JOOQ, JDBI, JdbcTemplate i pare innych rozwiązań ale ich nie używałem

3

W sumie sam poniekąd sobie odpowiedziałeś - jak masz Clean Architecture to masz odzielne encje JPA i oddzielne biznesowe. Należy zwrócić uwagę że korzystanie z encji JPA w wyższych warstwach jest problematyczne(np lazy loading po zakończeniu transakcji, dirty checking itp)
Dodatkowo też zaleca się stosowanie Value Objectow w modelu domenowym, zamiast mieć String email lepiej mieć Email email bo to jest o wiele czytelniejsze, a gdy masz encje biznesowe związane z JPA to musiałbyś mappery, albo stosować zwykle Stringi, Integery itp w encji JPA.
A to tym że Twoje pytanie sugeruje ze nie znasz w pełni celów czystej architektury nie wspomnę ;)

0

@scibi92 właśnie o to pytam, czy jest sens korzystać z JPA jeśli chcemy mieć zupełnie nieświadomą warstwę domeny? Kolega wyżej @KamilAdam napisał, że lazy loading jest drogą na skróty ale w przypadku nieprawidłowo zaprojektowanych agregatów w formie wielkich klastrów z masą zagnieżdżonych encjij. Jeśli mamy prawidłowo zaprojektowany agregat ze stałą liczbą encji, powiedzmy 20 encji, które z również mają po 20 encji, w tym wypadku lazy loading jest dużą optymalizacją

A to tym że Twoje pytanie sugeruje ze nie znasz w pełni celów czystej architektury nie wspomnę ;)

W takim razie byłbym wdzięczny gdybyś mi wytknął błąd

2

Ale JPA to nie warstwa domeny tylko warstwa persystencji! Odnośnie zastosowania Clean Architecture - celem jest m. in.
1)możliwość opoźnienia decyzji "technicznych" - na przykład czy stosujemy SQL, noSQL czy pliki albo po prostu RAM
2)ułatwienie zmian technologicznych - np zmianę Jdbc na JPA

0

@scibi92 jak najbardziej (oprócz tego, że JPA to warstwa), nie wiem co w mojej wypowiedzi sugeruje coś przeciwnego?

0

Zacząłeś trochę z drugiej strony, ale może się mylę. Tak czy inaczej należy pamiętać że encja w rozumieniu ORM to coś innego niż encja biznesowa.

0

@scibi92 wydaje mi się, że nie byłoby tematu gdybym nie znał tej różnicy.

1

Faktycznie, może źle Cię zrozumiałem. Myślę że sam fakt że mamy osobny model persystencji niż domenowy to nie jest wada jakiegoś rozwiązania, np w JOOQ też masz modele, no i na ogół model domenowy. Na ogol proces mapowania nie jest skomplikowany ani kosztowny. Ja bym JPA nie użył ale tylko dlatego że nie uważam JPA za najlepsza technologie delikatnie rzecz ujmując ;)

2

Nie bardzo rozumiem pytanie. Masz jakiśtam moduł persistence który potrafi na podstawie jakiegoś persistent store wypluwać obiekty domenowe. To czy dzieje się to za pomocą JPA, JDBC czy parsowania xmla nie ma znaczenia.

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