[mediateh7]

#programowanie #spring #java Mirki piszę aplikację m.in. z użyciem Spring JPA, i struktura mojego projektu wyglada tak, że mam tam sobie kontrolery, konfigurację i najważniejsze:
- Mam model, później mam repozytorium które rozszerza JpaRepository i później mam Service do którego sobie autowiruję repozytorium i z tego serwisu pobieram dane w kontrolerach. Czy to jakaś zła ( może dobra? ) praktyka ? Jeśli tak to co powiniem zmienić ?
Coś takiego jak w tym projekcie click

[splatch]

@mediateh7: Ogólnie przyjęta praktyka, jest taka jak robisz - czyli wszystko warstwowo, nie mniej w tym układzie często warstwa "service" jest tylko proxy do repozytoriów/dao na której konfiguruje się transakcje i ewentualnym miejscem gdzie wali się obejścia baboli, bo z DAO z kolei jest drętwą przykrywką na hibernate lub coś w ten deseń.

Ja już jakiś czas temu zrezygnowałem z tego i transakcje waliłem na poziomie kontrolera ;P Jeśli zastanawiasz się

[r.....3]

@mediateh7: Wszystko w porządku

[r.....3]

@splatch: Transakcje na poziomie kontrolera? Dlaczego nie w serwisach?

[splatch]

@roszd23: A co robią serwisy poza transakcjami skoro hibernate potrafi obsłużyć całe grafy powiązanych obiektów?

[splatch]

@roszd23: Serwis można zrobić to jakieś integracji zewnętrznej. A tak repozytoria mogą być wołane prosto z kontrolera. Mniej sztucznego kodu.

[K.....o]

@splatch: Imo transakcję powinny być na poziomie serwisów, a nie na samym repo.

[splatch]

@KawaCzibo: No właśnie pytanie jest co robią serwisy poza tą nieszczęsną transakcją? AOPowi bez różnicy na jakim poziomie @Transactional jest. Wątek i tak masz zarządzany przez jetty/tomcat cokolwiek innego i jest ten sam na poziomie kontrolera i serwisu.

[badAttitude]

Może i mnie zjedziecie, ale moim zdaniem nie programuje obiektowo ( ͡° ͜ʖ ͡°) service , managery, utilsy i inne gady zmuszają cię do programowania imperatywnego. Dlatego, że nie enkapsulujesz stanu tylko czynność jak już w takim podejściu. Ogólnie wrzuć w google "objects ending with er" po więcej info. O ile da Ci to ogólne podejście do wszelakiej maści workerów to z service'ami może to nie być już

[teherty]

Nic nie #!$%@?ł, proszę się rozejść.