Spring DAO vs Spring ORM vs Spring JDBC

Я использовал технологии доступа к данным, поддерживаемые Spring, и заметил, что в нем упоминаются несколько вариантов, и я не уверен в различии между ними:

Как я понимаю, Spring JDBC предоставляет шаблоны для сокращения шаблона кода для доступа к базе данных простым способом - вы пишете свои собственные SQL-запросы.

Spring -ORM предоставляет упрощенные шаблоны для доступа к базам данных через технологии ORM, такие как Hibernate, My (i) Batis и т.д.

Spring -DAO на веб-сайте Spring:

Поддержка объекта доступа к данным (DAO) в Spring направлена ​​на его создание легко работать с технологиями доступа к данным, такими как JDBC, Hibernate или JDO согласованным образом

Я немного разбираюсь в ORM vs JDBC, поскольку они нацелены на различные способы доступа к БД. Но Spring -DAO просто путают!

Неужели кто-нибудь может прояснить, какие именно различия между этими тремя? Что должно быть предпочтительным в тех сценариях?

Кроме того, доступен еще один проект Spring-DATA (http://projects.spring.io/spring-data/). Это своего рода родительский проект для всех данных технологии доступа, поддерживаемые Spring, или это просто новое имя для Spring -DAO?

Ответ 1

Вот введение к каждой упомянутой технологии.

Spring -DAO

Spring -DAO не является строгим senso spring модулем, а скорее соглашениями, которые должны диктовать вам писать DAO и писать их хорошо. Таким образом, он не предоставляет интерфейсы, ни реализации, ни шаблоны для доступа к вашим данным. При написании DAO вы должны аннотировать их с помощью @Repository, чтобы исключения, связанные с базовой технологией (JDBC, Hibernate, JPA и т.д.), Последовательно переводились в соответствующий подкласс DataAccessException.

В качестве примера предположим, что теперь вы используете Hibernate, и ваш сервисный уровень ловит HibernateException, чтобы реагировать на него. Если вы перейдете на JPA, ваши интерфейсы DAO не должны меняться, а уровень сервиса будет компилироваться с блоками, которые ловит HibernateException, но вы никогда не войдете в эти блоки, поскольку ваши DAO теперь бросают JPA PersistenceException. Используя @Repository в вашем DAO, исключения, связанные с базовой технологией, переведены на spring DataAccessException; ваш сервисный уровень ловит эти исключения, и если вы решите изменить технологию персистентности, то те же spring DataAccessExceptions все равно будут выбрасываться, поскольку spring переведут нативные исключения.

Обратите внимание, что это имеет ограниченное использование по следующим причинам:

  • Обычно вы не должны улавливать исключения настойчивости, поскольку поставщик может отменить транзакцию (в зависимости от точного подтипа исключения), и поэтому вы не должны продолжать выполнение с альтернативным путем.
  • Иерархия исключений обычно более богата вашим провайдером, чем предоставляет spring, и нет окончательного сопоставления от одного провайдера к другому. Опираясь на это, это опасно. Это, однако, хорошая идея, чтобы аннотировать ваши DAO с помощью @Repository, так как beans будет автоматически добавляться процедурой сканирования. Кроме того, spring может добавить в примечание другие полезные функции.

Spring -JDBC

Spring -JDBC предоставляет класс JdbcTemplate, который удаляет сантехнический код и помогает сосредоточиться на SQL-запросе и параметрах. Вам просто нужно сконфигурировать его с помощью DataSource, и вы можете написать код следующим образом:

int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);

Person p = jdbcTemplate.queryForObject("select first, last from person where id=?", 
             rs -> new Person(rs.getString(1), rs.getString(2)), 
             134561351656L);

Spring -JDBC также предоставляет JdbcDaoSupport, который вы можете расширить для разработки вашего DAO. Он в основном определяет 2 свойства: DataSource и JdbcTemplate, которые оба могут использоваться для реализации методов DAO. Он также предоставляет исключения, переводящие из SQL-исключений в spring DataAccessExceptions.

Если вы планируете использовать простой jdbc, это модуль, который вам нужно будет использовать.

Spring -ORM

Spring -ORM - это зонтичный модуль, который охватывает многие технологии персистентности, а именно JPA, JDO, Hibernate и iBatis. Для каждой из этих технологий spring предоставляет классы интеграции, поэтому каждая технология может использоваться в соответствии с принципами конфигурации spring и плавно интегрируется с управлением транзакциями spring.

Для каждой технологии конфигурация в основном состоит в том, чтобы вставить DataSource bean в какой-то тип SessionFactory или EntityManagerFactory и т.д. bean. Для чистого JDBC нет необходимости в таких классах интеграции (кроме JdbcTemplate), поскольку JDBC использует только источник данных.

Если вы планируете использовать ORM, например JPA или Hibernate, вам не понадобится spring -jdbc, но только этот модуль.

Spring -Data​​strong >

Spring -Data - это зонтичный проект, который предоставляет общий API для определения доступа к данным (аннотации DAO +) более общим образом, охватывающим как источники данных SQL, так и NOSQL.

Первоначальная идея состоит в том, чтобы предоставить технологию, чтобы разработчик записывал интерфейс для DAO (методы поиска) и классы сущностей технологически-агностическим способом и только на основе конфигурации (аннотации к DAO и сущностям + spring конфигурация, будь то xml- или java-based), решает технологию внедрения, будь то JPA (SQL) или redis, hadoop и т.д. (NOSQL).

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

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

Spring -Data концентрируется на не-SQL-технологиях, но по-прежнему предоставляет модуль для JPA (единственная технология SQL).

Что дальше

Зная все это, вы должны решить, что выбрать. Хорошая новость заключается в том, что вам не нужно делать окончательный окончательный выбор для этой технологии. На самом деле, где находится ресурс spring: как разработчик, вы концентрируетесь на бизнесе при написании кода, и если вы это сделаете хорошо, изменение базовой технологии - это детализация реализации или конфигурации.

  • Определить модель данных с классами POJO для сущностей и методы get/set для представления атрибутов сущности и отношений с другими объектами. Вам обязательно нужно будет аннотировать классы и поля сущностей на основе технологии, но на данный момент POJO достаточно для начала. Просто сосредоточьтесь на бизнес-требованиях на данный момент.
  • Определите интерфейсы для ваших DAO. 1 DAO охватывает ровно 1 объект, но вам, разумеется, не потребуется DAO для каждого из них, так как вы должны иметь возможность загружать дополнительные объекты, перемещая отношения. Определите методы поиска по строгим соглашениям об именах.
  • Основываясь на этом, кто-то еще может начать работать на уровне сервисов с помощью mocks для ваших DAO.
  • Вы изучаете различные технологии персистентности (sql, no-sql), чтобы найти наилучшее соответствие вашим потребностям, и выберите один из них. Исходя из этого, вы аннотируете объекты и реализуете DAO (или пусть spring реализует их для вас, если вы решите использовать spring -data).
  • Если бизнес-требования развиваются, а технология доступа к данным недостаточна для поддержки (например, вы начали с JDBC и нескольких объектов, но теперь вам нужна более богатая модель данных, а JPA - лучший выбор), вам придется измените реализацию своих DAO, добавьте несколько аннотаций на свои сущности и измените конфигурацию spring (добавьте определение EntityManagerFactory). Остальная часть вашего бизнес-кода не должна видеть других последствий вашего изменения.

Примечание. Управление транзакциями

Spring предоставляет API для управления транзакциями. Если вы планируете использовать spring для доступа к данным, вы также должны использовать spring для управления транзакциями, так как они объединяются вместе очень хорошо. Для каждой технологии доступа к данным, поддерживаемой spring, существует соответствующий менеджер транзакций для локальных транзакций или вы можете выбрать JTA, если вам нужны распределенные транзакции. Все они реализуют один и тот же API, так что (еще раз) выбор технологии - это просто конфигурация, которая может быть изменена без дальнейшего влияния на бизнес-код.

Примечание: spring документация

Ссылки на документацию spring, которые вы упомянули, являются довольно старыми. Вот документация последней версии (4.1.6, охватывающая все темы):

Spring -data не является частью структуры spring. Существует общий модуль, который вы должны сначала прочитать, чтобы привыкнуть к принципам. Документацию можно найти здесь:

Ответ 2

Spring DAO ( D ata A ccess O bject): для операций с базой данных с использованием шаблона DAO, Это концепция обобщенная для доступа к JDBC и Hibernate, iBatis, JPA, JDO, использующим отдельные классы поддержки. И он обеспечивает обобщенную иерархию исключений, определяя аннотацию @Repository. Аннотация определяет контейнер Spring для Перевод исключений SQL из SQLException до Spring стратегия доступа к ресурсам - агностик DataAccessException иерархия.

то есть. специфичные для платформы исключения - это уловы, а затем повторно выбрасываются как один из исключенных исключений доступа к данным Spring.

введите описание изображения здесь

Spring JDBC: для чистого JDBC, который зависит только от DataSource и классов шаблонов, таких как JdbcTemplate, NamedParameterJdbcTemplate (wraps JdbcTemplate) и SimpleJdbcTemplate для уменьшения перекрестные проблемы, а также класс JdbcDaoSupport для вышеуказанных преимуществ.

Spring ORM: Для поддержки инструментов ORM, таких как Hibernate, JPA, iBatis... легко интегрируйте Spring впрыскивание DataSource вдоль wit SessionFactory для Hibernate, EntityManagerFactory для JPA, SQLMapClient для iBatis и т.д. Вместе с соответствующими классами DaoSupport.

Ответ 3

Вы создаете интерфейс типа SomeObjectDao, а затем создаете различные реализации этого интерфейса, например JdbcSomeObjectDao, HibernateSomeObjectDao. Затем в вашем классе SomeObjectService вы будете работать с интерфейсом SomeObjectDao и введете туда одну из конкретных реализаций. Поэтому каждая реализация SomeObjectDao будет скрывать детали, независимо от того, используете ли вы JDBC или ORM и т.д.

Обычно JDBC и различные реализации ORM генерируют разные исключения. Spring Поддержка DAO может сопоставлять эти различные, специфичные для технологии исключения для общих исключений Spring DAO. Таким образом, вы отделены от фактической реализации. Кроме того, Spring поддержка DAO предлагает набор абстрактных классов *DataSupport, которые еще больше помогают в разработке DAO. Таким образом, помимо реализации вашего интерфейса SomeObjectDao вы можете расширить один из классов Spring *DataSupport.