для чего нужен паттерн dao
Забудьте о DAO, используйте Repository
Недавно задумался о том, чем отличаются паттерны, позволяющие абстрагироваться от работы с хранилищем данных. Много раз поверхностно читал описания и различные реализации DAO и Repository, даже применял их в своих проектах, видимо, до конца не понимая концептуальных отличий. Решил разобраться, закопался в Google и нашел статью, которая для меня разъяснила все. Подумал, что неплохо было бы перевести ее на русский. Оригинал для англочитающих здесь. Остальным интересующимся добро пожаловать под кат.
Data Access Object (DAO) — широко распространенный паттерн для сохранения объектов бизнес-области в базе данных. В самом широком смысле, DAO — это класс, содержащий CRUD методы для конкретной сущности.
Предположим, что у нас имеется сущность Account, представленная следующим классом:
Создадим интерфейс DAO для данной сущности:
Паттерн Repository
Лучшим решением будет использование паттерна Repository. Эрик Эванс дал точное описание в своей книге: «Repository представляет собой все объекты определенного типа в виде концептуального множества. Его поведение похоже на поведение коллекции, за исключением более развитых возможностей для построения запросов».
Вернемся назад и спроектируем AccountRepository в соответствии с данным определением:
Методы add и update выглядят идентично методам AccountDAO. Метод remove отличается от метода удаления, определенного в DAO тем, что принимает Account в качестве параметра вместо userName (идентификатора аккаунта). Представление репозитория как коллекции меняет его восприятие. Вы избегаете раскрытия типа идентификатора аккаунта репозиторию. Это сделает вашу жизнь легче в том случае, если вы захотите использовать long для идентрификации аккаунтов.
Если вы задумываетесь о контрактах методов add/remove/update, просто подумайте об абстрации коллекции. Если вы задумаетесь о добавлении еще одного метода update для репозитория, подумайте, имеет ли смысл добавлять еще один метод update для коллекции.
Однако, метод query является особенным. Я бы не ожидал увидеть такой метод в классе коллекции. Что он делает?
Репозиторий отличается от коллекции, если рассматривать возможности для построения запросов. Имея коллекцию объектов в памяти, довольно просто перебрать все ее элементы и найти интересующий нас экземпляр. Репозиторий работает с большим набором объектов, чаще всего, находящихся вне оперативной памяти в момент выполнения запроса. Нецелесообразно загружать все аккаунты в память, если нам необходим один конкретный пользователь. Вместо этого, мы передаем репозиторию критерий, с помощью которого он сможет найти один или несколько объектов. Репозиторий может сгенерировать SQL запрос в том случае, если он использует базу данных в качестве бекэнда, или он может найти необходимый объект перебором, если используется коллекция в памяти.
Одна из часто используемых реализаций критерия — паттерн Specification (далее спецификация). Спецификация — это простой предикат, который принимает объект бизнес-области и возвращает boolean:
Итак, мы можем создавать реализации для каждого способа выполнения запросов к AccountRepository.
Обычная спецификация хорошо работает для репозитория в памяти, но не может быть использована с базой данных из-за неэффективности.
Для AccountRepository, работающего с SQL базой данных, спецификации необходимо реализовать интерфейс SqlSpecification:
Репозиторий, использующий базу данных в качестве бекэнда, может использовать данный интерфейс для получения параметров SQL запроса. Если бы в качестве бекэнда для репозитория использовался Hibernate, мы бы использовали интерфейс HibernateSpecification, который генерирует Criteria.
SQL- и Hibernate-репозитории не используется метод specified. Тем не менее, мы находим наличие реализации данного метода во всех классах преимуществом, т.к. таким образом мы сможем использовать заглушку для AccountRepository в тестовых целях а также в кеширующей реализации репозитория перед тем, как запрос будет направлен непосредственно к бекэнду.
Мы даже можем сделать еще один шаг и использовать композицию Spicification с ConjunctionSpecification и DisjunctionSpecification для выполнения более сложных запросов. Нам кажется, что данный вопрос выходит за рамки статьи. Заинтересованный читатель может найти подробности и примеры в книге Эванса.
Шаблон DAO в Java
Узнайте, как реализовать шаблон объекта доступа к данным (DAO) в Java, чтобы изолировать уровни персистентности и бизнес-уровни вашего приложения.
1. Обзор
Функциональность этого API заключается в том, чтобы скрыть от приложения все сложности, связанные с выполнением операций CRUD в базовом механизме хранения. Это позволяет обоим слоям развиваться отдельно, ничего не зная друг о друге.
Дальнейшее чтение:
Введение в весенние данные JPA
Обзор типов каскадов JPA/Hibernate
2. Простая Реализация
Чтобы понять, как работает шаблон DAO, давайте создадим базовый пример.
2.1. Класс Домена
Поскольку наше приложение будет работать с пользователями, нам нужно определить только один класс для реализации его модели домена:
Класс User является простым контейнером для пользовательских данных, поэтому он не реализует никакого другого поведения, заслуживающего внимания.
Конечно, наиболее релевантный выбор дизайна, который нам нужно сделать здесь, заключается в том, как изолировать приложение, использующее этот класс, от любого механизма сохранения, который может быть реализован в какой-то момент.
Ну, это именно та проблема, которую пытается решить шаблон DAO.
2.2. API DAO
Давайте определим базовый слой DAO, чтобы мы могли увидеть, как он может полностью отделить модель домена от уровня персистентности.
2.3. Класс UserDao
Давайте определим пользовательскую реализацию интерфейса Dao :
Конечно, легко рефакторировать другие методы, чтобы они могли работать, например, с реляционной базой данных.
Хотя оба класса User и UserDao сосуществуют независимо в одном приложении, нам все равно нужно посмотреть, как последний можно использовать для сохранения уровня персистентности, скрытого от логики приложения:
3. Использование шаблона С JPA
Среди разработчиков существует общая тенденция полагать, что выпуск JPA снизил функциональность шаблона DAO до нуля, поскольку шаблон становится просто еще одним уровнем абстракции и сложности, реализованным поверх того, который предоставляется менеджером сущностей JPA.
3.1. Класс JpaUserDao
То JpaUserDao класс способен работать с любой реляционной базой данных, поддерживаемой реализацией JPA.
Кроме того, если мы внимательно посмотрим на класс, мы поймем, как использование Composition и Dependency Injection позволяет нам вызывать только методы entity manager, требуемые нашим приложением.
Проще говоря, у нас есть специализированный API для конкретного домена, а не API всего менеджера сущностей.
3.2. Рефакторинг пользовательского класса
В этом случае мы будем использовать Hibernate в качестве реализации JPA по умолчанию, поэтому мы соответствующим образом рефакторингуем класс User :
3.3. Программная загрузка менеджера сущностей JPA
В большинстве случаев мы достигаем этого с помощью типичного “persistence.xml” файл, что является стандартным подходом.
3.4. Класс UserApplication
Наконец, давайте проведем рефакторинг исходного Пользовательского приложения класса, чтобы он мог работать с экземпляром JpaUserDao и выполнять операции CRUD над сущностями User :
Даже если пример действительно довольно ограничен, он остается полезным для демонстрации того, как интегрировать функциональность шаблона DAO с той, которую предоставляет менеджер сущностей.
Кроме того, мы могли бы поменять MySQL на любую другую СУБД (и даже на плоскую базу данных) в дальнейшем, и все же наше приложение продолжало бы работать, как ожидалось, благодаря уровню абстракции, обеспечиваемому интерфейсом Dao и менеджером сущностей.
4. Заключение
В этой статье мы подробно рассмотрели ключевые концепции шаблона DAO, как реализовать его в Java и как использовать его поверх менеджера сущностей JPA.
Data Access Object (DAO). Уровень класса
При проектировании информационной системы выявляются некоторые слои, которые отвечают за взаимодействие различных модулей системы. Соединение с базой данных является одной из важнейшей составляющей приложения. Всегда выделяется часть кода, модуль, отвечающающий за передачу запросов в БД и обработку полученных от неё ответов. В общем случае, определение Data Access Object описывает его как прослойку между БД и системой. DAO абстрагирует сущности системы и делает их отображение на БД, определяет общие методы использования соединения, его получение, закрытие и (или) возвращение в Connection Pool.
Вершиной иерархии DAO является абстрактный класс или интерфейс с описанием общих методов, которые будут использоваться при взаимодействии с базой данных. Как правило, это методы поиска, удаление по ключу, обновление и т.д.
Набор методов не является завершённым, он зависит от конкретной системы. Фиктивный тип K является ключом сущности, редкая таблица, описывающая сущность, не имеет первичного ключа. Так же, в данном классе будет логичным разместить метод закрытие экземпляра PrepareStatement.
Уровень класса
Реализация DAO на уровне класса подразумевает использование одного единственного коннекта для вызова более чем одного метода унаследованного DAO класса. В этом случае, в вершине иерархии DAO AbstractController, в качестве поля объявляется connection. Абстрактный класс будет выглядеть следующим образом.
Экземпляр Connection доступен методу getPrepareStatement(String sql), который в свою очередь доступен любому методу конкретного DAO класса. Стоит помнить, что следует закрывать экземпляр PrepareStatement сразу после его отработки в блоках finally, а возвращать соединение в пул returnConnectionInPool() в части логики системы, где был вызван метод.
Использование паттерна data access object в клиентском приложении
Авторизуйтесь
Использование паттерна data access object в клиентском приложении
Всем привет! В этой статье я поделюсь своим опытом по работе с базой данных в приложении для Android. Это будет один из вариантов реализации паттерна data access object на языке Java.
Постановка задачи
Заказчик, который занимается предстраховыми осмотрами автомобилей, хочет автоматизировать рабочий процесс. Задача приложения — собирать и передавать на обработку данные об автомобиле.
Проектирование показало, что у приложения будет 3 модуля:
Сущности
Доступ к данным
Выделим для этих сущностей 3 вида доступа. В данном случае это будут следующие интерфейсы:
Далее создадим data access object, который предоставляет доступы. Этот интерфейс будет выглядеть так:
Теперь у нас есть все необходимые виды доступа, но пока они не запрашивают и не изменяют данные.
Модели данных
Готовый осмотр будет состоять из элементов, а элементы из данных. Нужно реализовать возможность получения осмотра по ключу, построение списка черновиков осмотров, списка готовых осмотров, а также возможность удалить осмотр. Таким образом, для всех подсущностей осмотра создадим модели:
Теперь передадим доступам их модели:
Теперь наш data access object готов.
Использование data access object
У нас есть три модуля. Каждый из них получит доступ только к той области базы данных, которая необходима для выполнения его задач.
Для сравнения посмотрите на код, который используется для получения данных, если не использовать DAO:
Обратите внимание, что класс неявно получает зависимость от конкретной реализации SQLite. Более того, он получает доступ ко всем частям базы данных, хотя не должен иметь возможности читать, изменять и удалять данные вне его круга задач. А вот как выглядит реализация аналогичной задачи с применением DAO:
Тестирование
Реализация
Заключение
Используя DAO, можно удобно разделять уровни доступа при работе с базой данных, чётко видеть эти уровни доступа и легко оперировать ими, не привязываясь к конкретной реализации хранения данных. Это позволяет применять такой подход вместе с TDD и точнее настраивать реализацию работы с БД (без изменений в других модулях) или полностью заменить одну реализацию на другую.
Блог сурового челябинского программиста
Are you aware how much time I’ve spent learning for details of Java? Thread management, dynamics, CORBA.
понедельник, 21 июля 2014 г.
О спорном паттерне DAO
В последние годы, после выхода спецификации Java EE 6, среди разработчиков и архитекторов информационных систем развернулась нешуточная дискуссия на тему паттерна DAO. Некоторые архитекторы и евангелисты уверены, что данный паттерн устарел и является избыточным решением в эпоху инъектируемого сразу в EJB- или CDI-компоненты JPA EntityManager’а. Другие же упорно настраивают на необходимости его применения.
Давайте попробуем разобраться в данном вопросе.
Паттерн DAO предназначен для отделения взаимодействия с хранилищем данных от бизнес-логики приложения. Т.е. вся логика, отвечающая за сохранение, изменение, извлечение сущностей выносится в отдельные DAO-классы, а код, инкапсулирующий бизнес-логику приложения (т.н. сервисы), взаимодействует с этими классами, а не непосредственно с хранилищем данных. Такой подход обеспечивает гибкость в выборе подсистемы хранения для приложения. Если необходимо перейти с использования ORM на прямое взаимодействие с базой данных посредством JDBC или отказаться от использования внутреннего хранилища данных для приложения и перейти на взаимодействие с системой управления мастер-данными посредством веб-сервисов, то достаточно только заменить реализацию DAO.
При этом большинство методов сервисов будут иметь подобную реализацию:
Т.е. логики практически нет, но зато добавление новой бизнес-операции выливается в четыре рутинных действия, выполнять которые быстро надоедает всем без исключения разработчикам.
Но важно даже не это, в конце концов человек ко всему привыкает. Главное то, что выполнять их не зачем, прозрачной смены подсистемы хранения паттерн DAO на самом деле не предоставляет. Каждый рекламируемый вариант замены реализации DAO (переключение между ORM и JDBC, между реляционными СУБД и NoSQL, между СУБД и веб-сервисами и т.д.) имеет свои подводные камни и практически всегда требует внесения изменений в слой бизнес-логики.
1. Переключение между ORM и JDBC. ORM-фреймворки, в отличие от JDBC реализуют прозрачное хранение (т.н. transparent persistence). Если после загрузки объекта в сессию обратиться к его сеттерам, то после синхронизации сессии с базой данных эти изменения будут отражены в ней. При использовании же JDBC такой прозрачности нет, поэтому любые изменения необходимо явно синхронизировать с базой данных посредством вызова соответствующих методов DAO, а значит требуется добавить обращение к этим методами в слой бизнес-логики, т.к. ранее, при использовании ORM, они отсутствовали.
2. Переключение с традиционной реляционной СУБД на NoSQL-хранилище тоже не всегда можно сделать прозрачно. Большинство NoSQL-хранилищ не поддерживают транзакции в терминах ACID. Бизнес-логику, реализуемую в сервисах, придется адаптировать к нетранзакционному хранилищу. Например, для повышения быстродействия мы могли исключить некоторые проверки из бизнес-логики, надеясь, что в СУБД отработают ограничения целостности, а в случае их нарушения будет выброшено исключение и произойдет откат транзакции. Если же транзакции нет, то изменения, выполненные до момента выбрасывания исключения, сохранятся в БД, что приведет к нарушению целостности данных.
3. Аналогичные соображения можно высказать и относительно перехода с использования реляционной СУБД на взаимодействие с внешним хранилищем посредством веб-сервисов. Контекст транзакции по веб-сервисам без использования специальных техник, таких как WS-AtomicTransaction, не передается, а применение данных техник не всегда возможно, а там где возможно ведет к существенному снижению производительности.