Data Access Object – obiekt dostępu do danych — abstrakcja źródła danych; komponent dostarczający jednolity interfejs do komunikacji między aplikacją a źródłem danych (np. bazą danych czy plikiem). Jest często łączony z innymi wzorcami projektowymi. DAO jest obiektem odwzorowującym źródło danych, enkapsulującym wszystkie dane przesyłane do i ze źródła. Dzięki DAO, aplikacja nie musi znać sposobu oraz ostatecznego miejsca składowania swoich danych, a ewentualne modyfikacje któregoś z czynników nie pociągają za sobą konieczności modyfikowania jej kodu źródłowego. Komponent ten jest często stosowany w modelu MVC (Model-View-Controller) do oddzielenia dostępu do danych od logiki biznesowej i warstwy prezentacji. Gotowe narzędzia do korzystania z DAO wchodzą w skład wielu popularnych języków programowania oraz platform (np. Java EE, Ruby on Rails).
W katalogu Core J2EE Patterns DAO jest opisywany jako wzorzec warstwy integracji (integration tier): ma izolować pozostałe komponenty aplikacji od szczegółów implementacyjnych źródeł danych oraz centralizować kod dostępu do danych (np. zapytania SQL). W tym ujęciu DAO działa jako adapter pomiędzy komponentem korzystającym z danych a konkretnym mechanizmem dostępu do danych, tak aby zmiany po stronie źródła danych nie wymuszały zmian w kodzie warstwy wyższej.
Opis wzorca wyróżnia typowe role składowe: BusinessObject – klient danych (np. komponent warstwy biznesowej lub prezentacji), który potrzebuje odczytu i zapisu danych. DataAccessObject – obiekt pośredniczący, który enkapsuluje logikę dostępu do danych (łączenie, wykonywanie operacji, mapowanie danych) i udostępnia klientowi uproszczony interfejs. DataSource – konkretna implementacja źródła danych (np. relacyjna baza danych, repozytorium XML, system plików, usługa zewnętrzna lub inne systemy). ValueObject – obiekt przenoszący dane pomiędzy DAO a klientem (pokrewny koncepcji DTO). W literaturze Core J2EE Patterns opisano m.in.: Strategię z fabryką DAO (np. z użyciem Abstract Factory), w której klient pozyskuje konkretne implementacje DAO zależnie od typu/producenta źródła danych (np. różne bazy danych), co ma wspierać migrację między implementacjami persystencji. Generowanie kodu DAO (na podstawie metadanych lub introspekcji schematu bazy) oraz wykorzystanie narzędzi ORM do mapowania obiektów na strukturę składowania, co może redukować koszt ręcznego utrzymania warstwy DAO w większych systemach. W praktyce DAO bywa zestawiany z innymi wzorcami warstwy persystencji: We wzorcu Repository nacisk kładzie się na „kolekcjowy” interfejs dostępu do obiektów domenowych i pośredniczenie między warstwą domeny a warstwą mapowania danych, aby zachować separację zależności. We wzorcu Data Mapper mapowanie między obiektami w pamięci a bazą danych realizuje warstwa mapperów, utrzymując niezależność obiektów domenowych od mechanizmów persystencji. W takim ujęciu DAO może pełnić rolę adaptera do konkretnego API źródła danych, podczas gdy mapowanie obiektów domenowych może być realizowane wewnątrz DAO (ręcznie) albo przez warstwę mapperów/ORM.
Wydajność W opisie wzorca jako konsekwencję wskazuje się m.in. to, że DAO wprowadza dodatkową warstwę obiektów pomiędzy klientem danych a źródłem danych, którą trzeba zaprojektować, zaimplementować i utrzymywać. W praktyce oznacza to kompromis między izolacją komponentów od szczegółów źródła danych oraz łatwością migracji a kosztem dodatkowej warstwy pośredniej (zarówno projektowym, jak i implementacyjnym). W praktyce dodanie DAO do aplikacji powoduje pojawienie się kolejnej warstwy interfejsu oraz zwiększenie ilości kodu, który musi zostać wykonany do realizacji dostępu do danych. Z tego powodu w aplikacjach, dla których wydajność ma krytyczne znaczenie, rezygnuje się z DAO, aby zapewnić jak najszybsze działanie aplikacji.
Zobacz też mapowanie obiektowo-relacyjne obiekt transferu danych wzorzec projektowy
Przypisy
Linki zewnętrzne Core J2EE Patterns – Data Access Object
Kategoria:Bazy danych