Obiekt dostępu do danych - Data access object
W oprogramowaniu komputerowym , A Data Access Object ( DAO ) jest wzór, który zapewnia abstrakcyjny interfejs do pewnego rodzaju bazy danych lub innego mechanizmu trwałości. Mapując wywołania aplikacji do warstwy trwałości, DAO zapewnia określone operacje na danych bez ujawniania szczegółów bazy danych. Ta izolacja wspiera zasadę pojedynczej odpowiedzialności . Oddziela, jakiego dostępu do danych potrzebuje aplikacja, w zakresie obiektów i typów danych specyficznych dla domeny (publiczny interfejs DAO), od tego, w jaki sposób potrzeby te mogą być zaspokojone przez określony DBMS , schemat bazy danych itp. (Implementacja DAO).
Chociaż ten wzorzec projektowy ma równe zastosowanie w większości języków programowania, większości typów oprogramowania wymagającego trwałości i większości typów baz danych, jest on tradycyjnie kojarzony z aplikacjami Java EE i relacyjnymi bazami danych (dostęp do nich uzyskuje się za pośrednictwem interfejsu API JDBC ze względu na Wytyczne dotyczące najlepszych praktyk firmy Microsystems „Core J2EE Patterns” dla tej platformy).
Zalety
Podstawową zaletą korzystania z obiektów dostępu do danych jest stosunkowo proste i rygorystyczne oddzielenie dwóch ważnych części aplikacji, które mogą, ale nie powinny, nic o sobie wiedzieć i od których można oczekiwać, że będą ewoluować często i niezależnie. Zmiana logiki biznesowej może polegać na tym samym interfejsie DAO, podczas gdy zmiany w logice trwałości nie wpływają na klientów DAO, o ile interfejs pozostaje poprawnie zaimplementowany.
Wszystkie szczegóły przechowywania są ukryte przed resztą aplikacji (patrz ukrywanie informacji ). W ten sposób możliwe zmiany w mechanizmie trwałości można zaimplementować, modyfikując tylko jedną implementację DAO, podczas gdy reszta aplikacji nie ma wpływu. DAO pełnią rolę pośrednika między aplikacją a bazą danych. Przenoszą dane tam iz powrotem między obiektami i rekordami bazy danych. Testowanie jednostkowe kodu jest ułatwione poprzez zastąpienie DAO podwójnym testem w teście, dzięki czemu testy są niezależne od warstwy trwałości.
W ogólnym kontekście języka programowania Java , Data Access Objects jako koncepcja projektowa może być implementowana na wiele sposobów. Może to obejmować dość prosty interfejs, który oddziela części dostępu do danych od logiki aplikacji, po struktury i produkty komercyjne. Paradygmaty kodowania DAO mogą wymagać pewnych umiejętności. Technologie takie jak Java Persistence API i Enterprise JavaBeans są wbudowane w serwery aplikacji i mogą być używane w aplikacjach korzystających z serwera aplikacji JavaEE. Produkty komercyjne, takie jak TopLink, są dostępne w oparciu o mapowanie obiektowo-relacyjne (ORM). Popularne oprogramowanie ORM typu open source obejmuje implementacje Doctrine , Hibernate , iBATIS i JPA, takie jak Apache OpenJPA .
Niedogodności
Potencjalne wady używania DAO obejmują nieszczelną abstrakcję , duplikację kodu i inwersję abstrakcji . W szczególności abstrakcja DAO jako zwykłego obiektu Java może ukryć wysoki koszt każdego dostępu do bazy danych, a także może zmusić programistów do wyzwalania wielu zapytań do bazy danych w celu pobrania informacji, które w przeciwnym razie mogłyby zostać zwrócone w ramach jednej operacji przy użyciu operacji zestawu SQL . Jeśli aplikacja wymaga wielu DAO, może się okazać, że powtarzasz zasadniczo ten sam kod tworzenia, czytania, aktualizowania i usuwania dla każdego DAO. Tego kodu podstawowego można jednak uniknąć, implementując ogólny DAO, który obsługuje te typowe operacje.
Hipotetyczny scenariusz użycia
Wyobraź sobie sytuację, w której jesteś właścicielem odnoszącej sukcesy firmy, która otrzymała kontrakty na opracowanie aplikacji dla dwóch różnych klientów. Specyfikacje aplikacji są prawie identyczne dla obu klientów. Obaj klienci zarządzają danymi za pomocą baz danych SQL, ale jedna firma korzysta z zastrzeżonej bazy danych, a druga korzysta z alternatywy typu open source, co oznacza, że warstwa trwałości aplikacji będzie musiała zostać wdrożona na dwa różne sposoby. Ponadto, gdy pojawią się nowi klienci, mogą być potrzebne dodatkowe implementacje. W takim przypadku użycie wzorca Data Access Object zapewniłoby odpowiednią ilość abstrakcji i hermetyzacji wymaganej do uzyskania dostępu do dowolnej z różnych baz danych zaplecza.
Narzędzia i frameworki
- System mapowania obiektowo-relacyjnego (ORM) oparty na kompilatorze ODB dla języka C ++
- ORMLite: Lekka struktura mapowania obiektowo-relacyjnego (ORM) w Javie dla JDBC i Androida
- Microsoft Entity Framework
- DBIx :: Class moduł mapowania obiektowo-relacyjnego (ORM) dla Perla
- TuxORM: Prosta biblioteka mapowania obiektowo-relacyjnego (ORM) w Javie dla JDBC
