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.
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
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ę ;)
@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
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
@scibi92 jak najbardziej (oprócz tego, że JPA to warstwa), nie wiem co w mojej wypowiedzi sugeruje coś przeciwnego?
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.
@scibi92 wydaje mi się, że nie byłoby tematu gdybym nie znał tej różnicy.
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 ;)
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.
@Shalom chodzi mi o to, żeby zrealizować w 100% clean architecture i jednocześnie stosować JPA muszę mieć dwa modele, a i tak nie daje mi to prawie żadnych zalet jak lazy-loading i czy w tym przypadku lepszy będzie lekki kompromis i małe dopasowanie obiektów domeny czy rezygnacja z ORM na rzecz jakiegoś lżejszego rozwiązania jak właśnie JDBC
wiem, że pewnie nie ma konkretnej odpowiedzi ale może macie jakieś doświadczenie w tym kierunku, co byłoby bardzo pomocne
Akurat ciężko lazy loading uznać za zalete ze względu na wydajność :)
muszę mieć dwa modele
O ile nie klepiesz CRUDa, to i tak musisz mieć. I nie że zmusza cię do tego jakaś technologia, tylko zwyczajnie zdrowy rozsądek i domena. Obiekty domenowe są generalnie dużo bardziej rozbudowane i dość naiwnym jest wiara w to że będą specjalnie podobne do modelu danych. Tak jak mówie -> to ma miejsce tylko jak piszesz generic cruda.
zalet jak lazy-loading
Jeśli ktoś uważa n+1 select za zaletę to decyzja JPA vs JDBC jest twoim najmniejszym problemem...
Ale tu właśnie wychodzi trochę niezrozumienie clean architecture. Cały myk polega właśnie na tym, żebyś tak to zaimplementował, żeby technologia persystencji danych nie miała żadnego znaczenia dla działania systemu ani w ogóle dla kodu domenowego.
Dodałbym do posta @Shalom że czysta architektura nie oznacza najlepszej możliwej dla danego problemu :) czysta architektura nie powinna być celem samym w sobie
@Charles_Rey
Dzieki, właśnie stąd pytanie o kompromisy
@Shalom
Jeśli ktoś uważa n+1 select za zaletę to decyzja JPA vs JDBC jest twoim najmniejszym problemem...
Nie wiedziałem że lazy loading wiąże się z wczytywaniem za każdym razem całych hierarchii encji. Człowiek uczy się przez całe życie...
eziomou napisał(a):
Mógłbym za każdym razem tworzyć oddzielny model dla warstwy persystencji jednak wprowadza to sporo dodatkowej pracy
Napisanie klasy i jej zmapowanie, nawet ręcznie, to jest troszeczkę dodatkowej pracy, która oszczędza sporo czasu na debugowaniu i poprawianiu.
jednocześnie pozbywam się zalet ORM takich jak lazy loading i śledzenie zmian.
Takie myki są akceptowalne, jak masz prostą domenę, anemiczny model, jesteś w stanie wszystko ogarnąć transaction scriptem, i wiesz co robisz, czyli np. nie wysyłasz tych biznesowo-bazowych encji na widok, bo wtedy n+1 masz gwarantowane.
Pewne zalety JPA (tak!) jak obserwowanie stanu obiektu, śledzenie zmian - BYŁY zaletami, jak to był desktop.
Są totalnie zbędne we współczesnych aplikacjach webowych, gdzie odczyt a zmiany/zapis to zuuupełnie inne części systemu, inny czas, być może nawet inny host. A kosztują pod względem wydajności, dużej komplikacji itd...