Czy korzystamy właściwie ze wzoru repozytorium?


14

Korzystamy z szeregu oddzielnych klas z przyrostkiem, -repositoryaby pobrać dane z bazy danych; dla każdej tabeli własne repozytorium.

Mamy na przykład customerrepositoryklasę, która ma wszelkiego rodzaju metody pozyskiwania klientów i vacancyrepositoryktóra ma wszelkiego rodzaju metody pozyskiwania wolnych miejsc pracy.

Mam dwa pytania dotyczące tego sposobu robienia rzeczy:

  1. Co powiesz na uzyskanie danych obejmujących wiele tabel? Na przykład mam ekran, który pokazuje wszystkich klientów, którzy nie utworzyli jeszcze wakatu. Czy customerrepositorymetody użycia z vacancyrespositoryobu repozytoriów mogą zwracać wyniki i czy istnieje klasa wyżej w hierarchii (nazwijmy ją a dataservice), która pobiera wyniki z obu repozytoriów i łączy je w jeden wynik?

  2. ile logiki może obsługiwać takie repozytorium?
    Myślę, że można zaimplementować w repozytorium „where active == true”, aby pobierać tylko aktywne rekordy, czy może nawet ta prosta logika powinna być obsługiwana przez klasę wyższą w hierarchii (nazwijmy to a dataservice)?

Przykład, na który teraz wpadałem, to ten:

Mamy listę pytań, która zawiera jedno lub więcej pytań.
Pytanie może mieć wynik, który jest przechowywany w osobnej tabeli.
Więc jeśli chcesz pobrać całkowity wynik listy pytań, musisz połączyć dane z questionlisttabeli, tabeli pytań i questionstatustabeli.

W tej chwili mamy 3 różne repozytoria dla tych tabel.

Gdybym zapytał, questionlistrepositoryjaki jest całkowity wynik dla listy nr 12, musiałby uzyskać dane z dwóch innych repozytoriów, a zatem miałby trochę logiki, czy to dozwolone?

A może istnieje taki, questionlistdataservicektóry wie, z których repozytoriów korzystać?

Jeszcze jedna rzecz: nasze repozytoria mogą powodować IQueryable, że usługa wywołująca może łatwo łączyć wyniki, ale co powiesz na to, kiedy tak nie jest, nie sądzę, że dobrym pomysłem jest odzyskanie całej zawartości wszystkich trzech tabel z Baza danych.


1
Zwykle w wielu dostępach do tabeli dominująca tabela jest określana przez tabelę rekordu, która musi istnieć, zanim zapytanie ją pobierze. W LEFT OUTER JOIN byłby to pierwszy wymieniony stół, aw RIGHT OUTER JOIN byłby drugi.
Neil

Odpowiedzi:


15

Repozytorium zwraca obiekty domeny i jest zbudowane na warstwach mapujących. W przypadku bardzo prostych domen domeny i tabele bazy danych mogą być bardzo podobne.

Jeśli Twoje repozytorium zawsze zwraca dokładną reprezentację struktury danych, może to być rzeczywiście Tabela Danych Bramowych, zwana też Obiektem Dostępu do Danych (DAO).

Przykład: Twoja baza danych zawiera tabele dotyczące osoby i adresu. W Twojej domenie aplikacji adres nie jest własnym podmiotem, jest tylko własnością Osoby. W takim przypadku nie byłoby PersonRepository i AddressRepository. Masz tylko PersonRepository. Domena nie powinna martwić się, w jaki sposób utrwalone są dane domeny. Ci odpowiedzialni są w warstwie za repozytorium.

Z twojego przykładu wydaje się, że faktycznie masz DAO i właśnie nazwałeś je Repozytoriami.


Dlatego podczas tworzenia repozytorium mogę mieć bramę danych tabeli o jeden poziom głębiej, a nasze repozytoria są w rzeczywistości TDG.
Michel

1
Możesz, ale zważ koszty i korzyści. Nie daj się zastraszyć utrzymywaniem oddzielności DAO i repozytoriów zgodnie z zasadą „warstwowania” kodu. Zrób to, co jest najbardziej czytelne w tym przypadku. Separacja i wynikowa warstwa abstrakcji mogą być przydatne, jeśli Twoje repozytoria często dokonują rekombinacji danych w DAO.
Mihai Danila
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.