Data Access Object
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.
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]- ↑ 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].
- ↑ 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.).
- ↑ 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.).
- ↑ 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.).
- ↑ 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.
- ↑ Martin Fowler, Repository [online], martinfowler.com [dostęp 2026-03-02].
- ↑ Martin Fowler, Data Mapper [online], martinfowler.com [dostęp 2026-03-02].
- ↑ a b Core J2EE Patterns – Data Access Object [online], Oracle [dostęp 2026-03-02].
- ↑ Chapter 24. Best Practices (Use hand-coded JDBC in bottlenecks) [online], Red Hat Documentation [dostęp 2026-03-02].