Próbuję odświeżyć swoje umiejętności projektowania wzorców i jestem ciekawy, jakie są różnice między tymi wzorami? Wszystkie wydają się być tym samym - hermetyzują logikę bazy danych dla określonej jednostki, aby kod wywołujący nie miał wiedzy o podstawowej warstwie trwałości. Z moich krótkich badań wynika, że wszystkie z nich zazwyczaj wdrażają standardowe metody CRUD i usuwają szczegóły specyficzne dla bazy danych.
Oprócz konwencji nazewnictwa (np. CustomerMapper, CustomerDAO, CustomerGateway, CustomerRepository), jaka jest różnica? Jeśli jest różnica, kiedy wybrałbyś jedną z nich?
W przeszłości pisałbym kod podobny do poniższego (oczywiście uproszczony - 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 mieć CustomerGatewayklasę, która implementuje określoną logikę bazy danych dla wszystkich metod. Czasami nie używałbym interfejsu i uczyniłbym wszystkie metody na CustomerGateway statycznymi (wiem, wiem, to sprawia, że jest mniej testowalny), więc mogę to nazwać tak:
Customer cust = CustomerGateway.GetCustomerByID(42);
Wydaje się, że jest to ta sama zasada dla wzorców mapowania danych i repozytorium; wzorzec DAO (który jest tym samym co Gateway, jak sądzę?) również wydaje się zachęcać do tworzenia bram specyficznych dla bazy danych.
Czy coś mi brakuje? To wydaje się trochę dziwne, mieć 3-4 różne sposoby robienia dokładnie tego samego.
źródło
W świecie projektowania oprogramowania istnieje tendencja (przynajmniej tak mi się wydaje) do wymyślania nowych nazw dla dobrze znanych starych rzeczy i wzorów. A kiedy mamy nowy paradygmat (który być może nieco różni się od już istniejących), zwykle zawiera on cały zestaw 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 żadna z nich nie jest w rzeczywistości czymś nowym i unikalnym, ale znowu: nowe nazwy dla znanych już koncepcji zebranych w tej samej książce). Więc nie mówię, że wszystkie te współczesne paradygmaty i akronimy oznaczają DOKŁADNIE to samo, ale naprawdę nie powinieneś być zbyt paranoikiem. W większości są to te same wzory, tylko z różnych rodzin.
źródło
Data Mapper a Table Data Gateway Krótko mówiąc:
W końcu oba będą działać jako mediator między obiektami w pamięci a bazą danych.
źródło
Masz rację. Wybierz ten, który znasz najlepiej. Chciałbym zwrócić uwagę na kilka rzeczy, które mogą pomóc w wyjaśnieniu.
Brama danych tabeli jest używana głównie w przypadku pojedynczej tabeli lub widoku. Zawiera wszystkie zaznaczenia, wstawienia, aktualizacje i usunięcia. Tak więc Klient to w Twoim przypadku stół lub widok. Tak więc jedno wystąpienie obiektu bramy danych tabeli obsługuje wszystkie wiersze tabeli. Zwykle jest to związane z jednym obiektem na tabelę bazy danych.
Chociaż Data Mapper jest bardziej niezależny od dowolnej logiki domeny i jest mniej sprzężony (chociaż uważam, że istnieje sprzężenie lub brak sprzężenia). Jest to jedynie warstwa pośrednicząca, która przesyła dane między obiektami a bazą danych, zachowując ich niezależność od siebie nawzajem i samego programu odwzorowującego.
Tak więc, zazwyczaj w programie mapującym, widzisz metody takie jak insert, update, delete, aw bramie danych tabeli znajdziesz getcustomerbyId, getcustomerbyName itp.
Obiekt transferu danych różni się od powyższych dwóch wzorców, głównie dlatego, że jest wzorcem dystrybucji, a nie wzorcem źródła danych, jak powyższe dwa wzorce. Używaj go głównie, gdy pracujesz ze zdalnym interfejsem i chcesz, aby połączenia były mniej rozmowne, ponieważ każde połączenie może być drogie. Dlatego zwykle projektuje się DTO, które można serializować za pośrednictwem kabla, który może przenosić wszystkie dane z powrotem na serwer w celu zastosowania dalszych reguł biznesowych lub przetwarzania.
Nie jestem dobrze zorientowany w wzorcu repozytorium, ponieważ do tej pory nie miałem okazji go użyć, ale będę szukał odpowiedzi innych.
źródło
Poniżej znajduje się tylko moje zrozumienie.
TableGateWay / RowDataGateWay : w tym kontekście Gateway odnosi się do konkretnej implementacji, w której każdy „obiekt domeny” ma odwzorowanie na każdą „bramę obiektu domeny”. Na przykład, jeśli mamy Person , będziemy mieć PersonGateway do przechowywania obiektu domeny Person w bazie danych. Jeśli mamy Osobę, Pracownika, Klienta itp., Będziemy mieć PersonGateway, EmployeeGateway i CustomerGateway. Każda brama będzie miała określoną funkcję CRUD dla tego obiektu i nie ma to nic wspólnego z inną bramą. Nie ma tutaj kodu / modułu wielokrotnego użytku. Bramkę można dalej podzielić na RowDataGateway lub TableGateway, w zależności od tego, czy przekażesz "id", czy "obiekt". Brama jest zwykle porównywana z rekordem aktywnym. Wiąże model domeny ze schematem bazy danych.
Repozytorium / DataMapper / DAO : To to samo. Wszystkie odnoszą się do warstwy trwałości, która przenosi jednostki bazy danych do modelu domeny. W przeciwieństwie do bramy, Repozytorium / DataMapper / DAO ukrywa implementację. Nie wiesz, czy za osobą znajduje się brama PersonGateway. Może, ale nie musi, nie obchodzi cię. Wiesz tylko, że dla każdego obiektu domeny muszą być obsługiwane operacje CRUD. Oddziela źródło danych od modelu domeny.
źródło