ORM Technologies против JDBC?

Ответ 1

Сложность.

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

JDBC/SQL. Если ваше приложение достаточно просто, чтобы просто представлять данные непосредственно из базы данных или отношения между ними достаточно просты.

В книге "Шаблоны архитектуры корпоративного приложения" Мартина Фаулера гораздо лучше объясняются различия между этими двумя типами:

Смотрите: Модель домена и Транзакция Script

Ответ 2

JDBC

• С JDBC разработчик должен написать код для отображения представления данных объектной модели в реляционную модель данных и соответствующую схему базы данных.
• С JDBC автоматическое сопоставление объектов Java с таблицами базы данных и обратное преобразование должно выполняться разработчиком вручную с помощью строк кода.
• JDBC поддерживает только собственный язык структурированных запросов (SQL). Разработчик должен найти эффективный способ доступа к базе данных, т.е. Выбрать эффективный запрос из нескольких запросов для выполнения одной и той же задачи.
• Приложение с использованием JDBC для обработки постоянных данных (таблиц базы данных), содержащих большой код базы данных. Код, написанный для сопоставления данных таблицы с объектами приложения и наоборот, состоит в том, чтобы сопоставить поля таблицы с объектами. По мере изменения таблицы или изменения базы данных необходимо изменить структуру объекта, а также изменить код, написанный для сопоставления таблицы-объекта/объекта-таблицы.
• С JDBC разработчики несут ответственность за обработку результирующего набора JDBC и преобразование его в объекты Java через код для использования этих постоянных данных в приложении. Таким образом, с помощью JDBC сопоставление между объектами Java и таблицами базы данных выполняется вручную.
• С JDBC кеширование поддерживается ручным кодированием.
• В JDBC нет проверки, что всегда каждый пользователь имеет обновленные данные. Эта проверка должна быть добавлена ​​разработчиком.

Hibernate.

• Hibernate - это гибкое и мощное решение ORM для сопоставления классов Java с таблицами базы данных. Hibernate сам позаботится об этом сопоставлении с использованием файлов XML, поэтому разработчику не нужно писать код для этого.
• Hibernate обеспечивает прозрачную персистентность, и разработчику не нужно явно писать код для сопоставления наборов таблиц базы данных с объектами приложения во время взаимодействия с РСУБД.
• Hibernate предоставляет мощный язык запросов Hibernate Query Language (независимый от типа базы данных), который выражается в знакомом синтаксисе SQL и включает полную поддержку полиморфных запросов. Hibernate также поддерживает собственные инструкции SQL. Он также выбирает эффективный способ выполнения задачи манипулирования базой данных для приложения.
• Hibernate предоставляет это отображение. Фактическое сопоставление между таблицами и объектами приложения выполняется в файлах XML. Если в базе данных или в любой таблице есть изменения, необходимо изменить свойства файла XML.
• Hibernate уменьшает количество строк кода, сохраняя само отображение объекта-таблицы и возвращает результат в приложение в виде объектов Java. Это избавляет программиста от ручной обработки постоянных данных, что сокращает время разработки и затраты на обслуживание.
• Спящий режим, с прозрачной стойкостью, кеш устанавливается на рабочее пространство приложения. Реляционные кортежи перемещаются в этот кеш в результате запроса. Это повышает производительность, если клиентское приложение много раз считывает одни и те же данные для одной и той же записи. Автоматическая прозрачная стойкость позволяет разработчику больше сосредоточиться на бизнес-логике, чем на коде приложения.
• Hibernate позволяет разработчику определять поле типа версии для приложения, из-за этого определенного поля Hibernate обновляет поле версии таблицы базы данных каждый раз, когда реляционный кортеж обновляется в виде объекта класса Java в эту таблицу. Поэтому, если два пользователя получают один и тот же кортеж, а затем изменяют его, а один пользователь сохраняет этот измененный кортеж в базу данных, версия автоматически обновляется для этого кортежа Hibernate. Когда другой пользователь пытается сохранить обновленный кортеж в базу данных, он не позволяет его сохранить, потому что у этого пользователя нет обновленных данных.

Ответ 3

Это также зависит от кривой обучения.

Ebean ORM имеет довольно низкую кривую обучения (простой API, простой язык запросов), если вы достаточно довольны аннотациями JPA для сопоставления ( @Entity, @Table, @OneToMany и т.д.).

Ответ 4

Я думаю, вы забыли посмотреть "Функциональное реляционное сопоставление"

Я бы подвел итог, сказав:

• Если вы хотите сосредоточиться на структурах данных, используйте ORM, например JPA/Hibernate
• Если вы хотите пролить свет на лечение, посмотрите библиотеки FRM: QueryDSL или Jooq
• Если вам нужно настроить SQL-запросы на определенные базы данных, используйте JDBC и собственные SQL-запросы

Эффективность различных технологий "Реляционное сопоставление" - мобильность: вы гарантируете, что ваше приложение будет работать на большинстве баз данных ACID. В противном случае вы сможете справиться с различиями между различными диалектами SQL при написании запросов SQL вручную.

Конечно, вы можете сдерживать себя стандартом SQL92 (а затем выполнять некоторое функциональное программирование) или вы можете повторно использовать некоторые концепции функционального программирования с фреймами ORM.

Силы ORM создаются поверх объекта сеанса, который может действовать как узкое место:

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

Тем не менее, его сильные стороны также являются его недостатками:

• Сессия должна иметь возможность сравнивать объекты, поэтому вам необходимо реализовать методы equals/hashCode Но равенство объектов должно основываться на "Бизнес-ключах", а не на идентификаторе базы данных (новые транзиторные объекты не имеют идентификатора базы данных!). Однако некоторые овеществленные понятия не имеют делового равенства (например, операция). Общее обходное решение основывается на GUID, которые склонны нарушать администраторы баз данных.

• Сессия должна отслеживать изменения связей, но ее правила сопоставления используют использование сборников, непригодных для бизнес-алгоритмов. Иногда вы хотели бы использовать HashMap, но ORM потребует, чтобы ключ был другим "Rich Object Object" вместо другого легкого... Затем вам нужно реализовать равенство объектов на объекте rich domain, действующем как ключ... Но вы не можете, потому что этот объект не имеет аналогов в мире бизнеса. Таким образом, вы возвращаетесь к простому списку, который вы должны выполнять итерации (и возникают проблемы с производительностью)

• ORM API иногда непригодны для использования в реальном мире. Например, веб-приложения реального мира пытаются обеспечить изоляцию сеанса, добавив некоторые предложения WHERE при получении данных... Тогда "Session.get(id)" недостаточно, и вам нужно обратиться к более сложному DSL (HSQL, Criteria API) или вернуться к собственному SQL

• Объекты базы данных конфликтуют с другими объектами, предназначенными для других фреймворков (например, OXM frameworks = Object/XML Mapping). Например, если ваши службы REST используют библиотеку джексона для сериализации бизнес-объекта. Но этот Джексон точно сопоставляется с Hibernate One. Затем либо вы объедините оба, и сильная связь между вашим API и вашей базой данных появится Или вы должны реализовать перевод, и весь код, который вы сохранили из ORM, потерян там...

С другой стороны, FRM представляет собой компромисс между "Реляционным сопоставлением объектов" (ORM) и собственными SQL-запросами (с JDBC)

Лучший способ объяснить различия между FRM и ORM заключается в принятии подхода DDD.

• Реляционное сопоставление объектов позволяет использовать "Rich Object Object", которые являются классами Java, состояния которых изменяются во время транзакции базы данных.
• Функциональное реляционное сопоставление основывается на "Бедных объектах домена", которые неизменяемы (так что вам нужно клонировать новый каждый раз, когда вы хотите изменить его содержимое).

Он освобождает ограничения, помещенные на сеанс ORM, и большую часть времени полагается на DSL над SQL (так что переносимость не имеет значения) Но, с другой стороны, вы должны изучить детали транзакции, проблемы concurrency

Список лиц = queryFactory.selectFrom(человек).где(   person.firstName.eq( "John" ),   person.lastName.eq( "Doe" )).fetch();