Плюсы и минусы использования шаблона DAO

Ответ 1

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

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

Ответ 2

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

PROS:

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

CONS:

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

PRO

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

CON

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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