Jaka jest różnica między maperem danych, bramką danych tabeli( Gateway), obiektem dostępu do danych (DAO) i wzorcami repozytoriów?
[3]}staram się odświeżyć moje umiejętności projektowania wzorów, i jestem ciekaw, jakie są różnice między tymi wzorami? Wszystkie z nich wydają się być tym samym - zawierają logikę bazy danych dla określonej jednostki, więc kod wywołujący nie ma wiedzy o podstawowej warstwie trwałości. Z moich krótkich badań wszystkie z nich zazwyczaj implementują swoje standardowe metody CRUD i abstrakcyjne dane specyficzne dla bazy danych.
Oprócz konwencji nazewnictwa (np. CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository), jaka jest różnica, jeśli w ogóle? Jeśli jest różnica, kiedy wybrałbyś jedno nad drugim?
W przeszłości pisałem kod podobny do następującego (uproszczony, naturalnie - normalnie nie używałbym właściwości publicznych):
public class Customer
{
public long ID;
public string FirstName;
public string LastName;
public string CompanyName;
}
public interface ICustomerGateway
{
IList<Customer> GetAll();
Customer GetCustomerByID(long id);
bool AddNewCustomer(Customer customer);
bool UpdateCustomer(Customer customer);
bool DeleteCustomer(long id);
}
I mają klasę CustomerGateway, która implementuje logikę bazy danych dla wszystkich metod. Czasami nie korzystam z interfejsu i robię wszystkie metody na kliencie statyczny (wiem, Wiem, to sprawia, że jest mniej testowalny), więc mogę go nazwać tak:
Customer cust = CustomerGateway.GetCustomerByID(42);
Wydaje się, że jest to ta sama zasada dla wzorców Mapera danych i repozytorium; wzór DAO (który jest tym samym, co Gateway, myślę?) wydaje się również zachęcać do bram specyficznych dla baz danych.
Czy coś przeoczyłem? Wydaje się trochę dziwne mieć 3-4 różne sposoby robienia dokładnie tego samego.5 answers
Twoje przykładowe terminy; DataMapper, DAO, DataTableGateway i repozytorium, wszystkie mają podobny cel (gdy go używam, oczekuję, że odzyskam obiekt klienta), ale inne intencje/znaczenie i wynikająca z tego implementacja.
A repozytorium "działa jak zbiór, z wyjątkiem bardziej rozbudowanych możliwości zapytań" [Evans, Domain Driven Design ] i mogą być traktowane jako "obiekty w pamięci" (dyskusja repozytorium )
A DataMapper "przenosi dane między obiektami a bazą danych, zachowując ich niezależność od siebie i samego mapera" (Fowler, PoEAA, Mapper )
A TableDataGateway to "Brama (obiekt, który zamyka dostęp do zewnętrznego systemu lub zasobu) do tabeli bazy danych. Jedna instancja obsługuje wszystkie wiersze w tabeli" (Fowler, PoEAA, TableDataGateway )
A DAO "oddziela klienta zasobu danych interfejs z mechanizmów dostępu do danych / dostosowuje API dostępu do określonego zasobu danych do ogólnego interfejsu klienta" pozwalając "mechanizmy dostępu do danych zmieniać się niezależnie od kodu wykorzystującego DANE" (Słońce )
Repozytorium wydaje się bardzo ogólne, nie ujawniając pojęcia interakcji z bazą danych. DAO zapewnia interfejs umożliwiający korzystanie z różnych podstawowych implementacji baz danych. TableDataGateway to specjalnie cienka owijka wokół pojedynczy stolik. DataMapper działa jako pośrednik umożliwiający obiektowi modelu ewolucję niezależnie od reprezentacji bazy danych (w czasie).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-25 18:08:12
Istnieje tendencja w świecie projektowania oprogramowania (przynajmniej tak mi się wydaje) do wymyślania nowych nazw dla znanych starych rzeczy i wzorców. A kiedy mamy nowy paradygmat (który być może nieco różni się od już istniejących rzeczy), zwykle przychodzi z całym zestawem nowych nazw dla każdego poziomu. Tak więc "logika biznesowa" staje się "warstwą Usług" tylko dlatego, że mówimy, że robimy SOA, a DAO staje się repozytorium tylko dlatego, że mówimy, że robimy DDD (i każde z nich nie jest w rzeczywistości czymś nowym i unikalnym, ale ponownie: nowe nazwy znanych już pojęć zebrane w tej samej książce). Nie mówię więc, że wszystkie te współczesne paradygmaty i akronimy oznaczają dokładnie to samo, ale naprawdę nie powinieneś być zbyt paranoiczny. Przeważnie są to te same wzory, tylko z różnych rodzin.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-30 18:12:51
Data Mapper vs Table Data Gateway By krótka historia:
W końcu oba będą działać jako mediator między obiektami w pamięci a bazą danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-07 00:54:34
Masz rację. Wybierz ten, z którym jesteś najbardziej zaznajomiony. Chciałbym zwrócić uwagę na kilka rzeczy, które mogą pomóc wyjaśnić.
Bramka danych tabeli jest używana głównie dla pojedynczej tabeli lub widoku. Zawiera wszystkie zaznaczenia, wstawianie, aktualizacje i usuwanie. Więc klient jest tabelą lub widokiem w Twoim przypadku. Tak więc jedna instancja obiektu bramki danych tabeli obsługuje wszystkie wiersze w tabeli. Zazwyczaj jest to związane z jednym obiektem na tabelę bazy danych.
Podczas gdy Data Mapper jest bardziej niezależny z dowolnej logiki domeny i jest mniej sprzężony (chociaż uważam, że albo jest sprzężenie, albo nie sprzężenie). Jest to jedynie warstwa pośrednicząca do przesyłania danych między obiektami a bazą danych, zachowując ich niezależność od siebie i samego mapera.
Tak więc, zazwyczaj w maperze widzisz metody takie jak insert, update, delete, a w tabeli data gateway znajdziesz getcustomerbyId, getcustomerbyName, itp.
Obiekt transmisji danych różni się od powyższych dwóch wzorców, głównie ponieważ jest to wzorzec dystrybucji, a nie wzorzec źródła danych, jak wyżej dwa wzorce. Używaj go głównie, gdy pracujesz ze zdalnym interfejsem i musisz wykonywać połączenia mniej rozmowne, ponieważ każde połączenie może być drogie. Tak więc zwykle Zaprojektuj DTO, które może być serializowane przez przewód, który może przenieść wszystkie dane z powrotem do serwera w celu zastosowania dalszych reguł biznesowych lub przetwarzania.
Nie jestem dobrze zorientowany w schemacie repozytorium, ponieważ do tej pory nie miałem okazji użyć, ale będę patrzył na inne odpowiedzi.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-04-30 00:03:33
Poniżej jest tylko moje zrozumienie.
TableGateWay / RowDataGateWay : W tym kontekście Gateway odnosi się do konkretnej implementacji, która ma mapowanie każdego "obiektu domeny" do każdej "bramy obiektu domeny". Na przykład, jeśli mamy Person, to będziemy mieli PersonGateway do przechowywania obiektu domeny Person w bazie danych. Jeśli mamy osobę, pracownika, klienta itp., będziemy mieli PersonGateway, EmployeeGateway i CustomerGateway. Każda brama będzie miała specyficzna funkcja CRUD dla tego obiektu i nie ma ona nic wspólnego z inną bramką. Nie ma tu kodu/modułu wielokrotnego użytku. Brama może być dalej podzielona na RowDataGateway lub TableGateway, zależy od tego, czy przekazujesz " id " lub "obiekt". Gateway jest zwykle porównywany z Active record. Łączy model domeny ze schematem bazy danych.
Repository / DataMapper / DAO: to to samo. Wszystkie odnoszą się do warstwy trwałości, która przenosi encje bazy danych do modelu domeny. W przeciwieństwie do gateway, repozytorium / DataMapper / DAO ukrywa implementację. Nie wiesz, czy za osobą kryje się osoba. Może, albo nie, nie obchodzi cię to. Wszystko, co wiesz, to to, że musi mieć operacje CRUD obsługiwane dla każdego obiektu domeny. To oddzielenie źródła danych i modelu domeny.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-04-13 18:49:24