Wpis z mikrobloga

Hej, mam aplikację webową w #java #spring, która przy uruchomieniu pobiera sobie część danych z DB przez JPA, oblicza na nich różne rzeczy i trzyma je razem z wynikami obliczeń w strukturach. Przy modyfikacji danych (zdarza się rzadko) nowe dane (i ich przeliczenia) lecą i do db, i do struktur.
Czy większy sens ma podział aplikacji na warstwy:
1. Jpa<-Dao<-Usługi<-Rest - Dao trzymają na stałe encje, które mają milion pól transient do przechowywania obliczeń, czy
2. Jpa<-Dao<-Managery<-Usługi<-Rest - Dao zapewniają wyłącznie dostęp do DB, a Managery trzymają całe struktury danych - już nie encje, a oddzielny zestaw klas
Jak to robicie w swoich aplikacjach i jak to się powinno robić?

#programowanie
  • 4
  • Odpowiedz
@lol_nope: przede wszystkim musisz odpowiedzieć sobie na pytanie jak bardzo skomplikowana jest albo będzie Twoja aplikacja. Jeżeli będzie ona prosta, to na Twoim miejscu wybrałbym coś podobnego do pierwszego sposobu a wszelkie obliczenia wykonywał po stronie serwisów (rzadne transienty). Generalnie z punktu widzenia architektonicznego dostaniesz niesłynny Anemic Domain Model a Twoja architektura przypomina wtedy wzorzec Transaction Script. Generalnie wtedy obiekty JPA najlepiej jakby przypominały brzydkie POJO z wyłącznie getterami i
  • Odpowiedz
@Ambidex: Dzięki za rozbudowaną odpowiedź.
Czyli w pierwszym sposobie serwisy przechowują wyniki obliczeń? Czy serwisy nie powinny być bezstanowe?
Chyba spróbuję DDD. Możesz polecić jakieś książki, kursy, przykłady aplikacji w spring z użyciem DDD? Nie bardzo sobie potrafię to na razie ułożyć i nie do końca mam pomysł na układ takiej aplikacji.
  • Odpowiedz
@lol_nope:
Serwisy bezstanowe są ogólnie o wiele łatwiejsze w implementacji. Generalnie przy pierwszym podejściu powinieneś wykonywać operację na obiektach JPA i od razu je zapisywać. W przypadku przechowywania wyników obliczeń albo na twoim miejscu stworzyłbym serwisy stanowe albo dodał jakieś cachowanie po stronie hibernate'a (2nd level cache), lub query cache ze springa (zwłaszcza jeśli modyfikacja danych zdarza się rzadko).
Jeśli chodzi o DDD to nigdy tego nie wykorzystywałem, więc średnio Ci
  • Odpowiedz
  • 0
@Ambidex: dzieki, artykuly zaczalem czytac i jakistam pomysl jak to rozplanowac juz mam, ale nie znalazlem rozwiazania jeszcze jednego problemu niezaleznie od podejscia: jezeli zapisze sobie cos do db, potem zmodyfikuje obiekty domeny/obiekty zapisane w service, a potem bedzie rollback, to przeciez nie cofnie mi zmian w obiektach. Da sie to jakos rozwiazac? Zapisywac historie zmian i implementowac sobie jakos XAResource albo samemu pilnowac rollbackow i commitow i cofac? To masakra
  • Odpowiedz