В компьютерном программном обеспечении объект доступа к данным ( DAO ) - это шаблон, который обеспечивает абстрактный интерфейс для некоторого типа базы данных или другого механизма сохранения. Сопоставляя вызовы приложений с уровнем сохраняемости, DAO предоставляет некоторые конкретные операции с данными, не раскрывая подробностей базы данных. Эта изоляция поддерживает принцип единой ответственности . Он отделяет то, какой доступ к данным требуется приложению с точки зрения объектов, зависящих от предметной области и типов данных (открытый интерфейс DAO), от того, как эти потребности могут быть удовлетворены с помощью конкретной СУБД , схемы базы данных и т. Д. (Реализация ДАО).
Хотя этот шаблон проектирования в равной степени применим к большинству языков программирования, большинству типов программного обеспечения с потребностями в постоянном хранении и большинству типов баз данных, он традиционно ассоциируется с приложениями Java EE и с реляционными базами данных (доступ к которым осуществляется через JDBC API из-за его происхождения в Sun Рекомендации Microsystems [1] «Основные шаблоны J2EE» для этой платформы).
Преимущества [ править ]
 | В этом разделе не процитировать любые источники . ( Февраль 2015 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Основным преимуществом использования объектов доступа к данным является относительно простое и строгое разделение между двумя важными частями приложения, которые могут, но не должны ничего знать друг о друге и которые, как ожидается, будут развиваться часто и независимо. Изменение бизнес-логики может полагаться на тот же интерфейс DAO, в то время как изменения в логике сохранения не влияют на клиентов DAO, пока интерфейс остается правильно реализованным.
Все детали хранилища скрыты от остальной части приложения (см. Скрытие информации ). Таким образом, возможные изменения в механизме сохраняемости могут быть реализованы путем простого изменения одной реализации DAO, в то время как остальная часть приложения не затрагивается. DAO действуют как посредник между приложением и базой данных. Они перемещают данные между объектами и записями базы данных. Модульное тестирование кода упрощается за счет замены DAO тестовым двойником в тесте, тем самым делая тесты независимыми от уровня сохраняемости.
В общем контексте языка программирования Java объекты доступа к данным как концепция дизайна могут быть реализованы несколькими способами. Это может быть довольно простой интерфейс, отделяющий части доступа к данным от логики приложения, до фреймворков и коммерческих продуктов. Парадигмы кодирования DAO могут потребовать определенных навыков. Такие технологии, как Java Persistence API и Enterprise JavaBeans, встроены в серверы приложений и могут использоваться в приложениях, использующих сервер приложений JavaEE. Коммерческие продукты, такие как TopLink , доступны на основе объектно-реляционного сопоставления (ORM). Популярное программное обеспечение ORM с открытым исходным кодом включает Doctrine , Hibernate ,Реализации iBATIS и JPA, такие как Apache OpenJPA .
Недостатки [ править ]
Потенциальные недостатки использования DAO включают вытекающую абстракцию , [ править ] дублирование кода и абстракцию инверсию . В частности, абстракция DAO как обычного объекта Java может скрыть высокую стоимость каждого доступа к базе данных, а также может заставить разработчиков запускать несколько запросов к базе данных для получения информации, которая в противном случае могла бы быть возвращена в одной операции с использованием операций набора SQL . Если приложению требуется несколько DAO, вы можете обнаружить, что повторяете по существу один и тот же код создания, чтения, обновления и удаления для каждого DAO. Однако этого шаблонного кода можно избежать, реализовав общий DAO, который обрабатывает эти общие операции. [2]
Гипотетический сценарий использования [ править ]
Представьте себе ситуацию, когда вы владеете успешной компанией, которая получила контракты на разработку приложения для двух разных клиентов. Спецификации приложения почти идентичны для двух клиентов. Оба клиента управляют данными с помощью баз данных SQL, но одна компания использует проприетарную базу данных, а другая - альтернативу с открытым исходным кодом, что означает, что уровень сохраняемости вашего приложения должен быть реализован двумя разными способами. Кроме того, по мере появления новых клиентов могут потребоваться дополнительные реализации. В этом случае использование шаблона объекта доступа к данным обеспечит необходимый объем абстракции и инкапсуляции, необходимый для доступа к любой из различных баз данных серверной части.
Инструменты и фреймворки [ править ]
- Система объектно-реляционного сопоставления (ORM) на основе компилятора ODB для C ++
- ORMLite: облегченная структура объектно-реляционного сопоставления (ORM) в Java для JDBC и Android [3]
- Microsoft Entity Framework
- DBIx :: Class модуль объектно-реляционного сопоставления (ORM) для Perl
- TuxORM: библиотека простого объектно-реляционного сопоставления (ORM) в Java для JDBC
См. Также [ править ]
- Создание, чтение, обновление и удаление (CRUD)
- Уровень доступа к данным
- Объекты служебных данных
Ссылки [ править ]
- ^ «Основные шаблоны J2EE - объекты доступа к данным» . Sun Microsystems Inc. 2 августа 2007 г.
- ^ См. Http://www.ibm.com/developerworks/java/library/j-genericdao/index.html для обходных путей.
- ^ Ходжсон, Кайл; Рид, Даррен (23 января 2015 г.). Поваренная книга ServiceStack 4 . Packt Publishing Ltd. стр. Глава 4. ISBN 9781783986576. Проверено 22 июня +2016 .
