За и против использования [закрытого] шаблона ДАО

Преимущества использования шаблона проектирования DAO

Шаблон проектирования DAO или объекта доступа к данным - хороший пример принципов, ориентированных на абстракцию и инкапсуляцию. Он разделяет логику персистентности - это отдельный уровень, называемый уровнем доступа к данным, который позволяет приложению безопасно реагировать на изменения в механизме персистентности. Например, если вы переключитесь с механизма персистентности на основе файлов на базу данных, ваше изменение будет ограничено уровнем доступа к данным и не повлияет на объекты сервисного уровня или домена. Объект доступа к данным или шаблон DAO в значительной степени стандартны в Java-приложении, будь то ядро ​​Java, веб-приложение или корпоративное приложение. Ниже приведены еще несколько преимуществ использования шаблона DAO в приложении Java:

1. Шаблон проектирования DAO также поддерживает связь. низкий между различными частями приложения. Используя шаблон проектирования DAO, ваш уровень просмотра полностью независим от уровня DAO, и от него зависит только уровень сервиса, который также абстрагируется с помощью интерфейса DAO.

2. Шаблон проектирования DAO позволяет выполнять тест JUnit быстрее, поскольку он позволяет создавать Mock и избегать подключения к базе данных для запуска тестов. Это улучшает тестирование, потому что написать тест с объектами Mock проще, чем тест интеграции с базой данных. В случае возникновения каких-либо проблем во время выполнения модульного теста вам нужно только проверять код, а не базу данных. Также щиты с проблемами подключения к базе данных и окружающей среды.

3. Поскольку шаблон DAO основан на интерфейсе, он также поддерживает принцип объектно-ориентированного проектирования «программирование для интерфейса, а не для реализации», что приводит к гибкому и качественному коду.

Мы увидели некоторую реальную пользу от внедрения шаблона DAO в нашу реализацию. Это связано главным образом с четким разделением между интерфейсом базы данных и реализацией. Мы наблюдали следующие преимущества:

• Абстракция для фактической реализации доступа к базе данных отделяет стратегию доступа к данным от бизнес-логики пользователя. Это позволило нам выбрать краткосрочную стратегию реализации (Spring JDBC Template) для начальной фазы проекта с возможностью перехода на IBATIS или Hibernate позднее. (Выбор, который мы не можем сделать в настоящее время.)
• Разделение вносит существенные преимущества в тестируемость, так как вся реализация доступа к данным может быть смоделирована в модульном тестировании. (Это, вероятно, самое большое преимущество)
• Комбинируя это с Spring, мы можем внедрить любую реализацию DB в выбранную нами систему (хотя это, возможно, говорит о DI больше, чем шаблон DAO).

Одной из проблем, с которой мы столкнулись, и это может быть связано с отсутствием ясности дизайна с нашей стороны, является «склонность» повторно использовать Объекты Значения Данных, опубликованные вне базы данных, как Объекты Передачи между последующей абстракцией. слои в архитектуре. Нашим решением после некоторой боли было создание объекта значения на слой (то есть, чтобы не использовать объекты значения базы данных в последующих архитектурных слоях).

ПРИМЕЧАНИЕ: вы можете найти и другие недостатки, но вот краткий список из моего опыта

ЗА:

• Общие вызовы для получения объектов.
• После того, как вы настроили общий поток создания / чтения / обновления / удаления, общий макет можно повторить для других DAO.
• Он также консолидирует то, куда может пойти специфическая для персистентности часть вашего кода. Отделяет бизнес-логику от других компонентов вашего кода.

МИНУСЫ:

• Это не самая гибкая вещь.
• Если вы хотите отложить загрузку некоторых дочерних объектов, вам придется либо смешивать DAO с другими слоями, либо принимать меры предосторожности при попытке получить ленивые объекты.
• Если вы пишете DAO от руки, код может стать утомительным и повторяющимся.

Pro: абстрактное разделение.
Против: шаблонный код (слава богу за генераторы кода / шаблоны и ORM).

Какую альтернативу вы рассматриваете?

Кажется довольно очевидным, что возложение ответственности за Устойчивость где-то еще, кроме уровня представления, обычно будет хорошей, просто из-за аргументов ясности ответственности и повторного использования. Я инстинктивно выбираю трехуровневый подход: презентация, обслуживание, настойчивость. Признаюсь, что делал это так долго, что не могу найти доказательств боли, которую я испытывал, если не делал этого. Мне кажется «очевидным», что наличие единственного уровня, который понимает механизм персистентности, должно упростить тестирование, облегчить обслуживание и дать хорошее разделение проблем.

Таким образом, остается вопрос о том, как именно сделать уровень персистентности. Мое предположение по умолчанию - использовать JPA (или аналогичные фреймворки). Я рассматриваю это как сложный пример DAO.

Итак, я вижу две стоимости DAO. Сначала вам нужно вложиться в структуру вашей программы, ее дизайн. Для тривиальных случаев это может показаться излишним. Во-вторых, если вы используете фреймворк, реализующий DAO, вам придется научиться. По сравнению с написанием кода JDBC напрямую, это еще одно вложение.

Сила шаблона DAO заключается в том, что он позволяет вам создать хороший уровень абстракции реальной системы хранения. Они обеспечивают более объектно-ориентированное представление уровня сохраняемости и четкое разделение между доменом и кодом, который фактически будет выполнять доступ к данным (прямой JDBC, структуры сохраняемости, ORM или даже JPA).

Если бы мне пришлось указать на слабость, я бы сказал, что это еще один уровень ... Но я думаю, это цена, которую нужно заплатить за то, чтобы не связывать свой код с базовым API персистентности.

PRO

• единая точка определения для таблицы БД - Отображение атрибутов объекта
• прозрачная возможность для реализаций DAO с другими типами хранилищ
• разработка шаблона интерфейса, которому следуют все DAO
• разработка более или менее стандартного тестового класса JUnit для результатов DAO в лучшем тестовом покрытии
• полный контроль над спецификой
• без потери производительности из-за слишком общего решения

CON

• менее «сексуально», чем при использовании последней версии framework
• разработчикам не приходится изобретать свои собственные колеса (может быть PRO: -))

Как и с большинством шаблонов разработки, использование DAO требует некоторого времени, чтобы привыкнуть. С опытом появляются преимущества более надежного кода и разработчиков, которые знают, почему все работает, а не только то, что кажется. Этот последний пункт является для меня самым большим преимуществом.

Предостережение,