![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 144 Pomógł: 0 Dołączył: 22.03.2015 Ostrzeżenie: (0%) ![]() ![]() |
Mam pytanie odnośnie persist i flush. Stworzyłem serwis gdzie wykonuje operacje na książkach, kataloguje je itd. Problem w tym, że nie wiem gdzie wykonać flush ? Czy zrobić to tak że w serwisie dać tylko persist a w kontrolerze flush ? Czy np. dodać fabryke która będzie zapisywała dane do bazy lub w repozytorium dać metodę add i tam zrobić persist i flush ?
|
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 623 Pomógł: 144 Dołączył: 22.12.2010 Ostrzeżenie: (0%) ![]() ![]() |
Imo bez sensu później szukać po kontrolerach gdzie jest flush, a gdzie go nie ma. Wykonujesz dany, konkretny zestaw zadań i robisz flush i tyle.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 144 Pomógł: 0 Dołączył: 22.03.2015 Ostrzeżenie: (0%) ![]() ![]() |
masz rację, jednak mam pytanie bo mam metodę create w serwisie która opdala fabryka(ona tworzy obiekt, tworzy unikalny kod ksiązki itd) i mam teraz pytanie czy flush powinnien iść w serwisie, w tej fabryce czy np. w repozytorium?
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 879 Pomógł: 189 Dołączył: 14.06.2006 Skąd: Bytom Ostrzeżenie: (0%) ![]() ![]() |
Tak jak napisałm Ci ohm. Utrwalanie obiektów powinieneś mieć właśnie w usługach, jak poszukasz w internecie to znajdziesz więcej na ten temat. Żeby była jasność, taka usługa powinna reprezentować jeden przypadek użycia.
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 428 Pomógł: 77 Dołączył: 10.07.2011 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Mam pytanie odnośnie persist i flush. Stworzyłem serwis gdzie wykonuje operacje na książkach, kataloguje je itd. Problem w tym, że nie wiem gdzie wykonać flush ? Czy zrobić to tak że w serwisie dać tylko persist a w kontrolerze flush ? Czy np. dodać fabryke która będzie zapisywała dane do bazy lub w repozytorium dać metodę add i tam zrobić persist i flush ? Usiądź nad Swoim kodem i zastanów się: - co robi usługa - fabryka - tworząca i uzupełniająca objekt, - co robi controller, - co się dzieje podczas flow bazując na tych danych ustalisz pewne kryteria obsługi obiektu encji, a co za tym idzie, odpowiedniego miejsca jej zapisu. Prosty przykład: Edytujesz obiekt poprzez formularz, validujesz i wszystko ładnie pięknie przechodzi, masz przynajmniej dwie opcje: a) zapiszesz w controllerze, (IMG:style_emoticons/default/cool.gif) zapiszesz poprzez dedykowaną usługę (np. manager), Wiesz jaka jest różnica między pkt. a a pkt. b? Jest taka, że jeżeli, z jakiegoś powodu, w innej akcji wprowadzisz zmiany na w/w obiekcie, to będziesz duplikował kod save'a, dlatego z pomocą przychodzi Ci rozwiązanie b, validujesz obiekt po stronie akcji (bądź wypychasz do usługi zajmującej się handlowaniem formularzy - polecam) i wywołujesz:
Kolejną zaletą w/w postępowania jest to, że masz gotową usługę, którą możesz injectować w inne usługi - reużywalność kodu, poza tym, Twoja akcja "save" może wykonywać jakieś inne, automagiczne zmiany związane lub nie z obiektem, wywalać eventy, co się tylko podoba. Ważną uwagą jest, abyś nie wpadł na "super" pomysł i nie budował listenera (kernel.terminate), tak aby zapisywał encje po obiegu requesta (IMG:style_emoticons/default/smile.gif) |
|
|
![]() ![]() |
![]() |
Aktualny czas: 22.08.2025 - 15:34 |