Hibernate, JPA и JDO – плюсы и минусы каждого?[закрыто]

StackOverflow https://stackoverflow.com/questions/530215

Вопрос

Я знаком с концепцией ORM и даже использовал nHibernate несколько лет назад для проекта .NET;однако я не следил за темой ORM в Java, и у меня не было возможности использовать какой-либо из этих инструментов.

Но теперь у меня может появиться возможность начать использовать некоторые инструменты ORM для одного из наших приложений, пытаясь отойти от ряда устаревших веб-сервисов.

Мне трудно объяснить разницу между спецификацией JPA, тем, что вы получаете с самой библиотекой Hibernate, и тем, что может предложить JDO.

Итак, я понимаю, что этот вопрос немного открытый, но я надеялся услышать некоторые мнения:

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

Решение

Некоторые примечания:

  • JDO и JPA — это спецификации, а не реализации.
  • Идея состоит в том, что вы можете поменять реализации JPA, если ограничите свой код использованием только стандартного JPA.(То же самое для JDO.)
  • Hibernate можно использовать как одну из таких реализаций JPA.
  • Однако Hibernate предоставляет собственный API с функциями, превосходящими возможности JPA.

ИМХО, я бы рекомендовал Hibernate.

Было несколько комментариев/вопросов о том, что вам следует делать, если вы нуждаться использовать функции, специфичные для Hibernate.Есть много способов взглянуть на это, но мой совет такой:

  • Если вас не беспокоит перспектива привязки к поставщику, сделайте выбор между Hibernate и другими реализациями JPA и JDO. включая различные расширения, специфичные для конкретного поставщика, при принятии решений.

  • Если вас беспокоит перспектива привязки к поставщику и вы не можете использовать JPA, не прибегая к расширениям, специфичным для поставщика, не используйте JPA.(То же самое для JDO).

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

Есть и другие факторы, например, насколько хорошо вы/ваши сотрудники знают соответствующие технологии, сколько продукты будут стоить при лицензировании и в чью историю вы верите о том, что произойдет в будущем с JDO и JPA.

Другие советы

Обязательно оцените реализацию JDO в DataNucleus.Мы начали с Hibernate, потому что он казался очень популярным, но довольно скоро поняли, что это не 100% прозрачное решение для сохранения данных.Слишком много предостережений, а документация полна фраз «если у вас возникла такая ситуация, вы должны написать свой код вот так», что лишает нас удовольствия от свободного моделирования и кодирования, как мы хотим.JDO имеет никогда заставило меня скорректировать свой код или модель, чтобы он «работал правильно».Я могу просто проектировать и кодировать простые POJO, как если бы я собирался использовать их только «в памяти», но при этом я могу сохранять их прозрачно.

Другое преимущество JDO/DataNucleus перед спящим режимом заключается в том, что он не требует всех накладных расходов на отражение во время выполнения и более эффективно использует память, поскольку использует улучшение байт-кода времени сборки (возможно, добавьте 1 секунду ко времени сборки для большого проекта), а не чем шаблон прокси-сервера с отражением во время выполнения спящего режима.

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

Вот пример разочарований, которые вы получите при использовании Hibernate и не получите при использовании JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Если вам нравится кодировать «обходные пути», то Hibernate, конечно, для вас.Если вы цените чистую, чистую, объектно-ориентированную, управляемую моделями разработку, в которой вы тратите все свое время на моделирование, проектирование и кодирование, а не на уродливые обходные пути, то потратьте несколько часов на оценку. JDO/DataNucleus.Вложенные часы окупятся тысячекратно.

Обновление: февраль 2017 г.

В течение некоторого времени DataNucleus реализует стандарт персистентности JPA в дополнение к стандарту персистентности JDO, поэтому перенос существующих проектов JPA из Hibernate в DataNucleus должен быть очень простым, и вы можете получить все вышеупомянутые преимущества DataNucleus с очень небольшим изменением кода. , если таковые имеются.Итак, с точки зрения вопроса, выбор конкретного стандарта: JPA (только СУРБД) или JDO (СУРБД + без SQL + СУБД + другие), DataNucleus поддерживает оба, Hibernate ограничен только JPA.

Производительность обновлений Hibernate DB

Еще один вопрос, который следует учитывать при выборе ORM, — это эффективность его механизма «грязной» проверки, который становится очень важным, когда ему необходимо создать SQL для обновления объектов, которые были изменены в текущей транзакции, особенно когда объектов много.В этом ответе SO содержится подробное техническое описание механизма грязной проверки Hibernate:JPA с вставкой HIBERNATE очень медленно

Недавно я оценил и выбрал структуру персистентности для Java-проекта, и мои выводы таковы:

Я вижу, что поддержка в пользу JDO это прежде всего:

  • вы можете использовать источники данных, отличные от SQL, db4o, hbase, ldap, bigtable, Couchdb (плагины для cassandra) и т. д.
  • вы можете легко переключиться с источника данных sql на источник данных, отличный от sql, и наоборот.
  • нет прокси-объектов и, следовательно, меньше проблем с реализациями hashcode() и Equals().
  • больше POJO и, следовательно, требуется меньше обходных путей
  • поддерживает больше отношений и типов полей

и поддержка в пользу JPA это прежде всего:

  • более популярным
  • Джейдо мертв
  • не использует расширение байт-кода

Я вижу много сообщений в поддержку JPA от разработчиков JPA, которые явно не использовали JDO/Datanucleus, предлагающих слабые аргументы в пользу отказа от использования JDO.

Я также вижу много сообщений от пользователей JDO, которые перешли на JDO и в результате стали намного счастливее.

Что касается большей популярности JPA, то, похоже, это отчасти связано с поддержкой поставщиков СУРБД, а не с ее техническим превосходством.(Для меня это звучит как VHS/Betamax).

JDO и его эталонная реализация Datanucleus явно не умерли, о чем свидетельствует принятие Google его для GAE и активная разработка исходного кода (http://sourceforge.net/projects/datanucleus/).

Я видел ряд жалоб на JDO из-за улучшения байт-кода, но пока не нашел объяснения, почему это плохо.

Фактически, в мире, который становится все более одержимым NoSQL-решениями, JDO (и реализация datanucleus) кажутся гораздо более безопасным выбором.

Я только начал использовать JDO/Datanucleus и настроил его так, чтобы я мог легко переключаться между использованием db4o и mysql.Для быстрой разработки полезно использовать db4o и не беспокоиться слишком сильно о схеме БД, а затем, как только схема стабилизируется, развернуть ее в базе данных.Я также уверен, что позже я смогу развернуть все или часть своего приложения в GAE или воспользоваться преимуществами распределенного хранилища/сокращения карт в стиле hbase/hadoop/cassandra без слишком большого рефакторинга.

Я обнаружил, что начальное препятствие при начале работы с Datanucleus немного сложное: документация на веб-сайте datanucleus немного сложна для понимания, а следовать учебным пособиям не так легко, как мне бы хотелось.Тем не менее, более подробная документация по API и сопоставлению становится очень полезной, как только вы пройдете начальную кривую обучения.

Ответ: это зависит от того, чего вы хотите.Я бы предпочел иметь более чистый код, отсутствие привязки к поставщику, более ориентированный на pojo, более популярные варианты nosql.

Если вам нужно теплое и суетливое ощущение, что вы делаете то же самое, что и большинство других разработчиков/овец, выберите JPA/hibernate.Если вы хотите стать лидером в своей области, протестируйте JDO/Datanucleus и примите собственное решение.

Что бы вы предложили для нового проекта?

Я бы не предложил ни того, ни другого!Используйте Spring DAO JdbcTemplate вместе с StoredProcedure, RowMapper и RowCallbackHandler вместо.

Мой личный опыт работы с Hibernate показывает, что сэкономленное заранее время с лихвой компенсируется бесконечными днями, которые вы потратите в дальнейшем, пытаясь понять и отладить такие проблемы, как неожиданное поведение каскадных обновлений.

Если вы используете реляционную БД, то чем ближе к ней ваш код, тем больше у вас контроля.Уровень DAO Spring позволяет точно контролировать уровень отображения, устраняя при этом необходимость в шаблонном коде.Кроме того, он интегрируется в уровень транзакций Spring, что означает, что вы можете очень легко добавлять (через AOP) сложное транзакционное поведение, не вторгаясь в ваш код (конечно, вы получаете это и с Hibernate).

JDO мертв

На самом деле JDO не умер, поэтому, пожалуйста, проверьте свои факты.JDO 2.2 был выпущен в октябре 2008 года JDO 2.3 находится в стадии разработки.

Он разрабатывается открыто под управлением Apache.Выпусков больше, чем было у JPA, а его спецификация ORM по-прежнему опережает даже предлагаемые функции JPA2.

JDO имеет расширенные функции, чем JPA. http://db.apache.org/jdo/jdo_v_jpa.html

Я использую JPA (реализация OpenJPA от Apache, основанная на кодовой базе KODO JDO, которой более 5 лет и которая чрезвычайно быстра и надежна).ИМХО, любой, кто говорит вам обходить спецификации, дает вам плохой совет.Я потратил время и был определенно вознагражден.С помощью JDO или JPA вы можете сменить поставщика с минимальными изменениями (JPA имеет сопоставление orm, поэтому мы говорим о возможной смене поставщика менее чем за день).Если у вас, как у меня, более 100 столов, это огромно.Кроме того, вы получаете встроенное кэширование с вытеснением кэша на уровне кластера, и все это хорошо.SQL/Jdbc подходит для высокопроизводительных запросов, но прозрачное сохранение намного лучше для написания алгоритмов и процедур ввода данных.Во всей моей системе всего около 16 SQL-запросов (более 50 тысяч строк кода).

Любой, кто говорит, что JDO мертв, является астроторговцем FUD, и они это знают.

JDO жив и здоров.Спецификация по-прежнему более мощная, зрелая и продвинутая, чем гораздо более молодая и ограниченная JPA.

Если вы хотите ограничиться только тем, что доступно в стандарте JPA, вы можете написать JPA и использовать DataNucleus как высокопроизводительную и более прозрачную реализацию персистентности, чем другие реализации JPA.Конечно, DataNucleus также реализует стандарт JDO, если вам нужна гибкость и эффективность моделирования, которые обеспечивает JDO.

Я сам изучал это и не нашел сильной разницы между ними.Я думаю, что большой выбор заключается в том, какую реализацию вы используете.Для себя я рассматривал DataNucleus платформа, поскольку она является независимой от хранилища данных реализацией обоих.

Я использовал Hibernate (реализация JPA) и JPOX (реализация JDO) в одном проекте.JPOX работал нормально, но довольно быстро столкнулся с ошибками, в том числе с некоторыми функциями языка Java 5, которые он в то время не поддерживал.У него были проблемы с транзакциями XA.Я создавал схему базы данных из объектов JDO.Он хотел каждый раз подключаться к базе данных, что раздражает, если ваше соединение с Oracle не работает.

Затем мы перешли в Hibernate.Некоторое время мы экспериментировали с использованием чистого JPA, но для сопоставления нам нужно было использовать некоторые специфические функции Hibernate.Запустить один и тот же код в нескольких базах данных очень просто.Hibernate, похоже, агрессивно кэширует объекты или иногда просто ведет себя странно.Есть несколько конструкций DDL, которые Hibernate не может обработать, поэтому они определяются в дополнительном файле, который запускается для инициализации базы данных.Когда я сталкиваюсь с проблемой Hibernate, часто многие люди сталкиваются с одной и той же проблемой, что упрощает поиск решений в Google.Наконец, Hibernate кажется хорошо спроектированным и надежным.

Некоторые другие респонденты предложили просто использовать SQL.Настоящий вариант использования реляционного сопоставления объектов — это тестирование и разработка.Базы данных, созданные для обработки больших объемов данных, обычно дороги и сложны в установке.С ними сложно тестировать.Существует множество баз данных Java в памяти, которые можно использовать для тестирования, но они обычно бесполезны для производства.Возможность использовать реальную, но ограниченную базу данных повысит производительность разработки и надежность кода.

В мае 2012 года я создал образец веб-приложения, использующего JDO 3.0 и DataNucleus 3.0 — посмотрите, насколько оно чистое:https://github.com/TorbenVesterager/BadAssWebApp

Ладно, возможно, это слишком чисто, потому что я использую POJO как для базы данных, так и для клиента JSON, но это весело :)

ПС:Содержит несколько аннотаций SuppressWarnings (разработанных в IntelliJ 11).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top