Jaka jest różnica między wzorcami DAO i repozytorium?

Jaka jest różnica między obiektami dostępu do danych (DAO) a wzorcami repozytoriów? Tworzę aplikację przy użyciu Enterprise Java Beans (EJB3), Hibernate ORM jako infrastruktury, oraz Domain-Driven Design (DDD) i Test-Driven Development (TDD) jako techniki projektowania.

DAOjest abstrakcją trwałości danych .
Repositoryjest abstrakcją zbioru obiektów .

DAObyłoby uważane za bliższe bazy danych, często koncentrujące się na tabelach.
Repositorybędzie uważany za bliższy do Domeny, zajmujący się tylko w Zbiorczych Korzeniach.

Repositorymożna zaimplementować za pomocą DAO's, ale nie zrobiłbyś czegoś przeciwnego.

Ponadto a Repositoryjest ogólnie węższym interfejsem. Powinno być po prostu zbiorem obiektów, z Get(id), Find(ISpecification), Add(Entity).

Metoda podobna Updatejest odpowiednia w przypadku DAO, ale nie w Repositoryprzypadku - gdy używasz Repository, zmiany w jednostkach byłyby zwykle śledzone przez oddzielne UnitOfWork.

Wydaje się, że implementacje nazywane Repositorysą w rzeczywistości bardziej DAO, a zatem myślę, że istnieje pewne zamieszanie co do różnicy między nimi.

OK, myślę, że mogę lepiej wyjaśnić, co umieściłem w komentarzach :). Zasadniczo możesz zobaczyć oba te same, chociaż DAO jest bardziej elastycznym wzorcem niż Repozytorium. Jeśli chcesz korzystać z obu, użyjesz Repozytorium w swoich DAO. Wyjaśnię każdy z nich poniżej:

MAGAZYN:

Jest to repozytorium określonego typu obiektów - umożliwia wyszukiwanie określonego typu obiektów oraz ich przechowywanie. Zwykle obsługuje TYLKO jeden typ obiektów. Np. AppleRepositoryPozwoli ci to zrobić AppleRepository.findAll(criteria)lubAppleRepository.save(juicyApple) . Pamiętaj, że repozytorium używa terminów modelu domeny (nie terminów DB - nic nie ma związku z tym, jak dane są utrwalane w dowolnym miejscu).

Repozytorium najprawdopodobniej będzie przechowywać wszystkie dane w tej samej tabeli, podczas gdy wzorzec tego nie wymaga. Fakt, że obsługuje tylko jeden typ danych, sprawia, że ​​logicznie jest on połączony z jedną główną tabelą (jeśli jest używany do trwałości DB).

DAO - obiekt dostępu do danych (innymi słowy - obiekt używany do uzyskania dostępu do danych)

DAO to klasa, która lokalizuje dane dla Ciebie (jest to przeważnie wyszukiwarka, ale zwykle jest używana do przechowywania danych). Wzorzec nie ogranicza Cię do przechowywania danych tego samego typu, dlatego możesz łatwo mieć DAO, który lokalizuje / przechowuje powiązane obiekty.

Np. Możesz łatwo mieć Userexe, który udostępnia metody takie jak

Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)

Wszystkie te są związane z użytkownikiem (i bezpieczeństwem) i można je określić w ramach tego samego DAO. Nie dotyczy to repozytorium.

Wreszcie

Zauważ, że oba wzorce naprawdę oznaczają to samo (przechowują dane i wyodrębniają dostęp do nich i oba wyrażone są bliżej modelu domeny i prawie nie zawierają żadnych odniesień DB), ale sposób ich użycia może być nieco inny, ponieważ DAO nieco bardziej elastyczny / ogólny, podczas gdy Repozytorium jest nieco bardziej szczegółowe i ogranicza się tylko do określonego typu.

Wzorzec DAO i repozytorium to sposoby implementacji warstwy dostępu do danych (DAL). Zacznijmy od DAL, po pierwsze.

Aplikacje obiektowe, które uzyskują dostęp do bazy danych, muszą mieć pewną logikę do obsługi dostępu do bazy danych. Aby zachować czystość i modułowość kodu, zaleca się odizolowanie logiki dostępu do bazy danych w osobnym module. W architekturze warstwowej tym modułem jest DAL.

Jak dotąd nie rozmawialiśmy o żadnej konkretnej implementacji: tylko ogólna zasada umieszczania logiki dostępu do bazy danych w osobnym module.

Jak możemy wdrożyć tę zasadę? Znanym sposobem implementacji tego, szczególnie w ramach takich jak Hibernacja, jest wzorzec DAO.

Wzorzec DAO to sposób generowania DAL, w którym zazwyczaj każda jednostka domeny ma swoje własne DAO. Na przykład Useri UserDao, Appointmenti AppointmentDaoitp. Przykład DAO z Hibernacją: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .

Co to jest wzorzec repozytorium? Podobnie jak DAO, wzór repozytorium jest również sposobem na osiągnięcie DAL. Głównym punktem wzorca repozytorium jest to, że z perspektywy klienta / użytkownika powinien on wyglądać lub zachowywać się jak kolekcja. Zachowanie się jak kolekcja nie oznacza, że ​​należy ją utworzyć Collection collection = new SomeCollection(). Zamiast tego oznacza, że ​​powinien obsługiwać operacje takie jak dodawanie, usuwanie, zawiera itp. To jest istota wzorca repozytorium.

W praktyce, na przykład w przypadku użycia hibernacji, wzór repozytorium jest realizowany za pomocą DAO. To jest wystąpienie DAL może być zarówno w tym samym wystąpieniu wzorca DAO i wzorca repozytorium.

Wzorzec repozytorium niekoniecznie jest czymś, co buduje się na DAO (jak niektórzy mogą sugerować). Jeśli DAO są zaprojektowane z interfejsem, który obsługuje wyżej wymienione operacje, jest to instancja wzorca repozytorium. Pomyśl o tym, jeśli DAO już zapewniają zbiór operacji podobny do kolekcji, to jaka jest potrzeba dodatkowej warstwy na nim?

Szczerze mówiąc, wygląda to na rozróżnienie semantyczne, a nie techniczne. Fraza Obiekt dostępu do danych w ogóle nie odnosi się do „bazy danych”. I chociaż można zaprojektować go tak, aby był zorientowany na bazę danych, myślę, że większość ludzi pomyślałaby o zrobieniu tego wady projektowej.

Celem DAO jest ukrycie szczegółów implementacji mechanizmu dostępu do danych. Czym różni się wzorzec repozytorium? O ile wiem, nie jest. Mówienie o repozytorium różni się od DAO, ponieważ masz do czynienia z / zwracaniem kolekcji obiektów, nie może mieć racji; DAO mogą również zwracać kolekcje obiektów.

Wszystko, co przeczytałem na temat wzorca repozytorium, wydaje się polegać na tym rozróżnieniu: zły projekt DAO vs. dobry projekt DAO (inaczej wzorzec projektu repozytorium).

Repozytorium jest bardziej abstrakcyjnym terminem zorientowanym na domenę, który jest częścią projektu opartego na domenie, jest częścią projektu domeny i wspólnego języka, DAO jest abstrakcją techniczną dla technologii dostępu do danych, repozytorium dotyczy tylko zarządzania istniejącymi danymi i fabrykami w celu tworzenia dane.

sprawdź te linki:

http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html

Kluczową różnicą jest to, że repozytorium obsługuje dostęp do zagregowanych katalogów głównych w agregacie, podczas gdy DAO obsługuje dostęp do encji. Dlatego powszechne jest, że repozytorium deleguje rzeczywistą trwałość zagregowanych katalogów głównych do DAO. Ponadto, ponieważ zagregowany katalog główny musi obsługiwać dostęp do innych podmiotów, może być konieczne przekazanie tego dostępu innym podmiotom DAO.

DAO zapewnia abstrakcję plików bazy danych / danych lub dowolnego innego mechanizmu trwałości, dzięki czemu warstwą trwałości można manipulować bez znajomości szczegółów jej implementacji.

Podczas gdy w klasach repozytorium można użyć wielu klas DAO w jednej metodzie repozytorium, aby wykonać operację z „perspektywy aplikacji”. Zamiast używać wielu DAO w warstwie domeny, użyj repozytorium, aby to zrobić. Repozytorium jest warstwą, która może zawierać pewną logikę aplikacji, taką jak: Jeśli dane są dostępne w pamięci podręcznej w pamięci, następnie pobierz je z pamięci podręcznej, w przeciwnym razie pobierz dane z sieci i zapisz w pamięci podręcznej w pamięci do następnego pobrania.

Repozytorium to nic innego jak dobrze zaprojektowane DAO.

ORM są skoncentrowane na stole, ale nie DAO.

Nie ma potrzeby używania kilku DAO w repozytorium, ponieważ samo DAO może zrobić dokładnie to samo z repozytoriami / podmiotami ORM lub dowolnym dostawcą DAL, bez względu na to, gdzie i jak utrwalony jest samochód 1 tabela, 2 tabele, n tabele, pół tabeli, a serwis internetowy, tabela i serwis internetowy itp. Usługi korzystają z kilku DAO / repozytoriów.

Moje własne DAO, powiedzmy, CarDA zajmuje się tylko Car DTO, to znaczy, bierze Car DTO tylko na wejściu i zwraca tylko kolekcje samochodów DTO lub samochodów DTO na wyjściu.

Tak więc, podobnie jak Repozytorium, DAO faktycznie jest IoC dla logiki biznesowej, pozwalając interfejsom persytencji nie być zastraszanym przez strategie perswazji lub dziedzictwo. DAO zarówno zawiera strategię trwałości, jak i udostępnia interfejs persytencji związany z domeną. Repozytorium to tylko jedno słowo dla tych, którzy nie zrozumieli, czym właściwie jest dobrze zdefiniowane DAO.

Spróbuj dowiedzieć się, czy DAO lub wzorzec repozytorium najlepiej nadaje się do następującej sytuacji: Wyobraź sobie, że chcesz zapewnić jednolity interfejs API dostępu do danych dla trwałego mechanizmu dla różnych typów źródeł danych, takich jak RDBMS, LDAP, OODB, repozytoria XML i płaskie pliki.

W razie zainteresowania zapoznaj się również z następującymi linkami:

http://www.codeinsanity.com/2008/08/repository-pattern.html

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

w bardzo prostym zdaniu: Istotną różnicą jest to, że Repozytoria reprezentują kolekcje, podczas gdy DAO są bliżej bazy danych, często bardziej skoncentrowane na tabelach.

W strukturze wiosennej znajduje się adnotacja zwana repozytorium, aw opisie tej adnotacji znajdują się przydatne informacje o repozytorium, które moim zdaniem są przydatne w tej dyskusji.

Wskazuje, że klasa z adnotacjami jest „repozytorium”, pierwotnie zdefiniowanym przez Domain-Driven Design (Evans, 2003) jako „mechanizm enkapsulacji przechowywania, pobierania i wyszukiwania, który emuluje kolekcję obiektów”.

Zespoły wdrażające tradycyjne wzorce Java EE, takie jak „Obiekt dostępu do danych”, mogą również zastosować ten stereotyp do klas DAO, jednak należy dołożyć starań, aby zrozumieć różnicę między Obiektem dostępu do danych a repozytoriami w stylu DDD. Ta adnotacja jest stereotypem ogólnego zastosowania, a poszczególne zespoły mogą zawęzić swoją semantykę i stosować ją odpowiednio.

Tak opisana klasa kwalifikuje się do tłumaczenia Spring DataAccessException, jeśli jest używana w połączeniu z PersistenceExceptionTranslationPostProcessor. Klasa z adnotacjami została również wyjaśniona co do jej roli w ogólnej architekturze aplikacji do celów oprzyrządowania, aspektów itp.