Przejdź do zawartości

Data Access Object

Z Wikipedii, wolnej encyklopedii

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)[1]. 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[1]. 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[2]. Komponent ten jest często stosowany w modelu MVC (Model-View-Controller) do oddzielenia dostępu do danych od logiki biznesowej i warstwy prezentacji[3]. 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)[4].

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)[5]. 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[5].

Opis wzorca wyróżnia typowe role składowe:

  • BusinessObject – klient danych (np. komponent warstwy biznesowej lub prezentacji), który potrzebuje odczytu i zapisu danych[5].
  • DataAccessObject – obiekt pośredniczący, który enkapsuluje logikę dostępu do danych (łączenie, wykonywanie operacji, mapowanie danych) i udostępnia klientowi uproszczony interfejs[5].
  • DataSource – konkretna implementacja źródła danych (np. relacyjna baza danych, repozytorium XML, system plików, usługa zewnętrzna lub inne systemy)[5].
  • ValueObject – obiekt przenoszący dane pomiędzy DAO a klientem (pokrewny koncepcji DTO)[5].

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[5].
  • 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[5].

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[6].
  • 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[7].

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[5].

Wydajność

[edytuj | edytuj kod]

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ć[8]. 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)[5]. 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[8][9].

Przypisy

[edytuj | edytuj kod]
  1. ↑ a b Mauricio F. Aniche, Gustavo A. Oliva, Marco A. Gerosa, Are the Methods in Your Data Access Objects (DAOs) in the Right Place? A Preliminary Study, IEEE, wrzesień 2014, s. 47–50, DOI: 10.1109/MTD.2014.14, ISBN 978-1-4799-6791-9 [dostęp 2024-07-19].
  2. ↑ Christine Mayr, Uwe Zdun, Schahram Dustdar, Model-Driven Integration and Management of Data Access Objects in Process-Driven SOAs, Petri Mähönen, Klaus Pohl, Thierry Priol (red.), Berlin, Heidelberg: Springer, 2008, s. 62–73, DOI: 10.1007/978-3-540-89897-9_6, ISBN 978-3-540-89897-9 [dostęp 2024-07-19] (ang.).
  3. ↑ Maurício Aniche, Gabriele Bavota, Christoph Treude, Marco Aurélio Gerosa, Arie van Deursen, Code smells for Model-View-Controller architectures, „Empirical Software Engineering”, 23 (4), 2018, s. 2121–2157, DOI: 10.1007/s10664-017-9540-2, ISSN 1573-7616 (ang.).
  4. ↑ Alain Trottier, Sun Java 2 Enterprise Edition (J2EE) Web Component Developer Exam: Exam 310-080, Que Publishing, 2002, s. 36, ISBN 978-0-7897-2821-0 (ang.).
  5. ↑ a b c d e f g h i j Deepak Alur, John Crupi, Dan Malks, Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall Professional, 2003, s. 371–379, ISBN 978-0-13-142246-9.
  6. ↑ Martin Fowler, Repository [online], martinfowler.com [dostęp 2026-03-02].
  7. ↑ Martin Fowler, Data Mapper [online], martinfowler.com [dostęp 2026-03-02].
  8. ↑ a b Core J2EE Patterns – Data Access Object [online], Oracle [dostęp 2026-03-02].
  9. ↑ Chapter 24. Best Practices (Use hand-coded JDBC in bottlenecks) [online], Red Hat Documentation [dostęp 2026-03-02].

Zobacz też

[edytuj | edytuj kod]

Linki zewnętrzne

[edytuj | edytuj kod]
Źródło: „https://pl.wikipedia.org/w/index.php?title=Data_Access_Object&oldid=79394262”