Przeglądając różne projekty, zauważyłem, że programiści często używają zamiennie tych pojęć. Mam na myśli klasę, z której korzysta prezentacja, i która korzysta z DAL, służącą do manipulacji naszymi obiektami. Czy ktoś mógłby wytłumaczyć, jaka jest różnica między tymi konstrukcjami? Na ile wyczytałem - Repository powinno być stosowane dla najprostszego CRUD i powinno się dla każdej encji tworzyć dedykowane, z kolei serwisy powinny zapewniać określone metody bardziej związane z logiką biznesową (np. serwis do zarządzania fakturami, zamówieniami), gdzie zawarte są inne, niestandardowe metody. Czy to jest poprawne podejście? Sam złapałem się na tym, że nazywam te obiekty albo z końcówką albo "Services" czy "Manager" (to jeszcze lepsze), właściwie niezależnie od tego, jaka jest ich zawartość.
Do CRUDa jest DAO.
Repozytorium odpowiada za operacje na domenie jak na liście.
darkrat napisał(a):
Na ile wyczytałem - Repository powinno być stosowane dla najprostszego CRUD i powinno się dla każdej encji tworzyć dedykowane
Nie wiem, gdzie to wyczytałeś, ale to jest całkowite zaprzeczenie Repository. Repository stosuje się w podejściu DDD, które ma zastosowanie do skomplikowanej logiki biznesowej, a nie prostego CRUDa.
http://commitandrun.pl/2016/05/11/Repozytorium_najbardziej_niepotrzebny_wzorzec_projektowy/
z kolei serwisy powinny zapewniać określone metody bardziej związane z logiką biznesową (np. serwis do zarządzania fakturami, zamówieniami), gdzie zawarte są inne, niestandardowe metody.
Serwis to bardzo szerokie pojęcie, są ich różne rodzaje, a do tego różni programiści różne rzeczy tak nazywają.
Ale ogólnie tak - klasy realizujące jakąś logikę biznesową możesz tak nazywać.
A samo pytanie bardzo dziwne - repozytoria służy tylko do pobierania i zapisywania obiektów do źródła, w przeciwieństwie do serwisów nie wykonują na nich żadnej logiki. To tak jakby pytać, czym się różni pralka od lodówki.
Jeśli w projekcie nie ma DDD, to Service (dostepu do danych) == DAO == Repository == Table Data Gateway wg Fowlera, ergo różnica jest tylko w nazwie, pod spodem jest zwykle to samo.
somekind napisał(a):
A samo pytanie bardzo dziwne - repozytoria służy tylko do pobierania i zapisywania obiektów do źródła, w przeciwieństwie do serwisów nie wykonują na nich żadnej logiki. To tak jakby pytać, czym się różni pralka od lodówki.
Właściwie dokładnie o to pytałem, tylko nie wiedziałem, co jest lodówką, a co pralką.
neves napisał(a):
Jeśli w projekcie nie ma DDD, to Service (dostepu do danych) == DAO == Repository == Table Data Gateway wg Fowlera, ergo różnica jest tylko w nazwie, pod spodem jest zwykle to samo.
I to muszę zgłębić, bo na ten moment tak to mniej więcej u mnie wygląda.
Dzięki za odpowiedzi:)
Crud to rzecz generyczna łącznie z widokiem można ją dostarczyć za pomocą biblioteki — lub jednego serwisu operującego bezpośrednio na ORM "normalnym ORM". Reszta, która ma jakąś wartość biznesową DM z Repository Serwisem, który odzwierciedla przypadki użycia.
Mam na myśli klasę, z której korzysta prezentacja, i która korzysta z DAL, służącą do manipulacji naszymi obiektami
To o czym mówisz to jest prawdopodobnie jakimś TS na potrzeby widoku, który oprócz prostej logiki jedyne co robi to wypluwa jakieś DTO, ablo Serivis CRudowy.
To nie tak, że projekt ma DDD albo nie ma. Dla większości ludzi DDD to przeniesienie wszystkich "encji z bazy" do DM zmiany SetName() Na ChangeName() no i jest DDD. DDD to coś znacznie więcej i pojawia się w projekcie, kiedy zaczynamy opisywać zachowanie biznesu, Crud to nie jest żadne zachowanie biznesu tylko aplikacji, ale może istnieć z DDD. Wiedzielibyście to, gdybyście zamiast czytać blogi, które najczęściej generują przetłumaczone wpisy od jakiegoś Hindusa. Przeczytali jakąś dobrą książkę.
Podejście typu albo robimy DDD, albo nie. Zwykle kończy się tym, że każda tabelka w bazie ma swój Serwis z metodami typu ChangeProduktDescription ale po co ? Co to jakiś event biznesowy? ;)
Sam Problem autora jest wynikiem fuzji śmieciowych Informacji na temat DDD, które, można znaleźć w sieci.
Nie mieliście o DDD w technikum informatycznym ?
neves napisał(a):
Jeśli w projekcie nie ma DDD, to Service (dostepu do danych) == DAO == Repository == [Table Data Gateway wg Fowlera], ergo różnica jest tylko w nazwie, pod spodem jest zwykle to samo.
DAO, Table Data Gateway to nie jest to samo co Repository. Gdybyś przeczytał, chociaż spis treści książki Fowlera "P of EAA" to byś wiedział, że Table Data Gateway to wzorzec źródła danych a Repository to wzorzec odwzorowania obiektów. Dwie zupełnie inne rzeczy i doczepo innego służą. Ale kogo to obchodzi...
Swoją drogą to, że pod spodem jest zwykle to samo, świadczy tylko o poziomie programistów, którzy nie odróżniają wzorców i nie rozumieją, do czego służą.
Moim zdaniem masz wypaczony światopogląd. Świat, w którym Repo to wzorzec dostępu do danych, to świat urojeń i czyijś wypaczeń. Ergonomia pfff. Rok po wydaniu książki do Javy, do której książka się silnie odnosi zostało dodane generyczne typowanie. A ludzie jakoś zdaje się nie zauważyli tego i dalej wystawiają 5 serwisów crudowych bo tyle mają tabelek w bazie, no i oczywiście w tym serwisie musi być Repo, nie wiadomo po co i dlaczego, a co to za różnica :).
W takim razie zastanawia mnie, czy pracując z EntityFrameworkiem, warto w ogóle programować DAO, który ma je właściwie wbudowane? Nie przypomina mi to nic innego jak dodatkowe 'opakowanie'.
Smutny Terrorysta napisał(a):
To nie tak, że projekt ma DDD albo nie ma.
No niestety, albo ma albo nie ma. Nie można mieć DDD zaimplementowanego w połowie.
Tyle, że DDD powinno się stosować tylko do tych modułów i ficzerów, w których to ma sens.
Crud to nie jest żadne zachowanie biznesu tylko aplikacji
Że niby przechowywanie danych, ich odczyt i edycja to nie są wymagania biznesowe? To kto je zatem wymyśla, programiści sami sobie?
darkrat napisał(a):
W takim razie zastanawia mnie, czy pracując z EntityFrameworkiem, warto w ogóle programować DAO, który ma je właściwie wbudowane? Nie przypomina mi to nic innego jak dodatkowe 'opakowanie'.
No właśnie nie warto. Witaj w świecie ludzi rozsądnych!
Niestety w życiu zawodowym spotkasz masę architektów, seniorów i innych przygłupów, którzy każą ci takie wrappery pisać. Bo tak było w tutorialu, z których się uczyli.
darkrat napisał(a):
W takim razie zastanawia mnie, czy pracując z EntityFrameworkiem, warto w ogóle programować DAO, który ma je właściwie wbudowane? Nie przypomina mi to nic innego jak dodatkowe 'opakowanie'.
No właśnie nie warto. Witaj w świecie ludzi rozsądnych!
Niestety w życiu zawodowym spotkasz masę architektów, seniorów i innych przygłupów, którzy każą ci takie wrappery pisać. Bo tak było w tutorialu, z których się uczyli.
Więc w takim razie jeśli pracujemy na klasycznym monolicie (prezentacja - logika - dal), a potrzebujemy wykonać metodę np. "GetAll()", to czy będzie poprawne trzymać w kontrolerze DatabaseContext? Zazwyczaj trzymałem to w DAL, do którego odwoływała się logika, natomiast w tym wypadku ten podział zostanie chyba nieco zaburzony, skoro "uderzymy" tam prosto z prezentacji.
No nie, uderzanie prosto z prezentacji to też jest zły pomysł. W warstwie biznesowej miej po prostu serwis, który będzie realizował w całości daną operację biznesową operując bezpośrednio na ORM. Z tego serwisu niech korzysta kontroler.
No ale jeśli mamy na przykład bardzo prosty formularz z danymi użytkownika, gdzie jedyne metody, które są nam potrzebne, to CRUD, to czy wtedy nie musimy napisać właśnie takiego wrappera? Oczywiście to co napisałeś jest dokładnie tym, co zamierzam realizować, ale co w przypadku bardzo prostych DAO?
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
somekind napisał(a):
No niestety, albo ma albo nie ma. Nie można mieć DDD zaimplementowanego w połowie.
Tyle, że DDD powinno się stosować tylko do tych modułów i ficzerów, w których to ma sens.
Mogę się zgodizć, ale DDD oferuje wiele różnych, technik, wzorców. Nie można powiedzieć, że zaimplementowałeś wszystkie i masz DDD. Ani, że wszystkie ficzery i moduły robisz w DDD dlatego, że projekt ma mieć DDD albo nie.
Przypomina mi to gadkę typu mam "Restowe API". :)
Że niby przechowywanie danych, ich odczyt i edycja to nie są wymagania biznesowe? To kto je zatem wymyśla, programiści sami sobie?
Z jakim dokładnie zachowaniem biznesowym ma coś wspólnego edycja etykiety, jak opis produktu, Jaką wartość dla aplikacji wnosi to, że zamodelujesz te "zachowanie" w DDD ? To trochę jak byś chciał mi powiedzieć, że do rejestracji użytkowników jest potrzebne DDD, bo biznes powiedział, że "potrzebuje panel logowania".
Że niby przechowywanie danych, ich odczyt i edycja to nie są wymagania biznesowe? To kto je zatem wymyśla, programiści sami sobie?
Nie zrozumieliśmy, się w kontekście DDD takie, operację, nie posiadają zachowania ważnego dla biznesu. Jest to rzecz oczywista, kolokwialna bazująca głównie na tym, że aplikacja jest aplikacją.
somekind napisał(a):
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
No tylko czy chcąc tego uniknąć, nie sprowadza się to do pisania niczego innego jak właśnie wrappera?
darkrat napisał(a):
somekind napisał(a):
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
No tylko czy chcąc tego uniknąć, nie sprowadza się to do pisania niczego innego jak właśnie wrappera?
Orm w kontrolerze to mniej więcej tak jakbyś sobie napisał QueryStringa do SQL w Kontrolerze....
Szalony Kura napisał(a):
darkrat napisał(a):
somekind napisał(a):
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
No tylko czy chcąc tego uniknąć, nie sprowadza się to do pisania niczego innego jak właśnie wrappera?
Orm w kontrolerze to mniej więcej tak jakbyś sobie napisał QueryStringa do SQL w Kontrolerze....
Zaiste zdaję sobie z tego sprawę. Pytam o skuteczne rozwiązanie problemu, a nie, czy on ma miejsce.
darkrat napisał(a):
Szalony Kura napisał(a):
darkrat napisał(a):
somekind napisał(a):
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
No tylko czy chcąc tego uniknąć, nie sprowadza się to do pisania niczego innego jak właśnie wrappera?
Orm w kontrolerze to mniej więcej tak jakbyś sobie napisał QueryStringa do SQL w Kontrolerze....
Zaiste zdaję sobie z tego sprawę. Pytam o skuteczne rozwiązanie problemu, a nie, czy on ma miejsce.
Rozwiązaniem, będzie "Wrap na ORM" który udostępnia interface Crud'a. Beztego nie separujesz abstrakcji. To tak jak byś chciał zbudować dom z architekturą, w której piwnica jest pod dachem budynku.
Szalony Kura napisał(a):
darkrat napisał(a):
Szalony Kura napisał(a):
darkrat napisał(a):
somekind napisał(a):
Nawet w przypadku prostego cruda nie korzystałbym z ORMa w kontrolerach.
No tylko czy chcąc tego uniknąć, nie sprowadza się to do pisania niczego innego jak właśnie wrappera?
Orm w kontrolerze to mniej więcej tak jakbyś sobie napisał QueryStringa do SQL w Kontrolerze....
Zaiste zdaję sobie z tego sprawę. Pytam o skuteczne rozwiązanie problemu, a nie, czy on ma miejsce.
Rozwiązaniem, będzie "Wrap na ORM" który udostępnia interface Crud'a. Beztego nie separujesz abstrakcji. To tak jak byś chciał zbudować dom z architekturą, w której piwnica jest pod dachem budynku.
Czyli rozumiem, że wrapy jednak mają sens, bo pozwalają oddzielić abstrakcję, czego bez nich byśmy nie uzyskali.
Szalony Kura napisał(a):
Mogę się zgodizć, ale DDD oferuje wiele różnych, technik, wzorców. Nie można powiedzieć, że zaimplementowałeś wszystkie i masz DDD. Ani, że wszystkie ficzery i moduły robisz w DDD dlatego, że projekt ma mieć DDD albo nie
Ale te moduły, które chcesz zaimplementować w DDD musisz wykonać w pełni zgodnie z DDD, żeby móc o nich mówić, że są w DDD.
Z jakim dokładnie zachowaniem biznesowym ma coś wspólnego edycja etykiety, jak opis produktu
Jaką wartość biznesową ma opis produktu? Podejrzewam, że ludzie niespecjalnie chcą kupować nieopisane produkty.
Jaką wartość dla aplikacji wnosi to, że zamodelujesz te "zachowanie" w DDD ?
A kto konkretnie chce to robić w DDD? Bo na pewno nie ja. Nie każde wymaganie biznesowe trzeba modelować w DDD.
darkrat napisał(a):
Czyli rozumiem, że wrapy jednak mają sens, bo pozwalają oddzielić abstrakcję, czego bez nich byśmy nie uzyskali.
To nie jest żaden wrapper, to rdzeń Twojej aplikacji, który po prostu korzysta z ORMa, aby trwale przechować dane. A kontroler to tylko taki klej, który łączy Twoją aplikację z konkretną technologią GUI. Kontrolerów mogłoby nie być, a aplikacja nadal mogła by działać i realizować wymagania biznesowe.