Плюсы и минусы использования шаблона DAO [закрыт]

Question

Как я упоминал в названии, мне интересно знать, что вы (как опытные разработчики) думаете об использовании шаблона DAO, особенно в веб-приложении.Какие преимущества вы обнаружили и какие последствия его использования вам не понравились?

Answer 1

Проблемы с DAO, которые я видел, заключаются в том, что они обычно постоянно обрабатывают полные объекты.Это создает совершенно ненужные накладные расходы, которых не было бы при простых запросах.Например, если раскрывающийся список должен быть создан на основе справочных данных базы данных, пользователь DAO может просто сказать:«Дайте мне коллекцию объектов для этой таблицы, где y упорядочен по z».Затем эти данные используются в раскрывающемся списке, но обычно только для комбинации ключ/значение, игнорируя все остальное в объектах (созданные данные, последний пользователь, который их обновил, независимо от того, активен он или нет и т. д.), которые были получены и сопоставлены. .Даже если это массирование происходит рядом с вызовом DAO, и объекты не сохраняются по мере их извлечения (что, как правило, не так, к сожалению, объекты часто заключаются в c:forEach (JSP) и повторяются для создания раскрывающегося списка). ), это по-прежнему создает ненужные нагрузки на базу данных и сеть, не говоря уже о временном увеличении памяти для хранения этих объектов.

Это не означает, что DAO не может быть спроектирован для получения карты справочных данных — это, безусловно, возможно.Но обычно они используются для полного сопоставления объектов, а это не то, что нужно постоянно.Это сильная сторона при сохранении, но, по моему мнению, слабость при извлечении данных - конечно, вы получаете все это - но часто вам не нужно все это, и это просто тратит память, пропускную способность и время.

Answer 2

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

ПЛЮСЫ:

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

МИНУСЫ:

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

ПРО

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

ПРОТИВ

• менее «сексуально», чем использование последней версии фреймворка
• разработчики не могут изобретать свои собственные колеса (может быть, ПРО :-))

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

Предостережение: в зависимости от вашей ситуации использование структуры персистентности может быть хорошей альтернативой кодированию собственных DAO.

Answer 7

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

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

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

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

Answer 8

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