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

174

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

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

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

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

  • Каковы плюсы и минусы каждого?
  • Что бы вы предложили для нового проекта?
  • Существуют ли определенные условия, когда имеет смысл использовать один фреймворк против другого?
java hibernate orm jpa jdo Мэтт Б
источник

Ответы:

112

Некоторые заметки:

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

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

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

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

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

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

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

Инструментарий
источник
8
инструментарий, красивый и короткий. Еще один момент, который стоит упомянуть, заключается в том, что JPA не препятствует использованию специфических функций реализации при необходимости. Это означает, что JPA позволяет использовать любую функцию Hibernate, когда Hibernate является реализацией.
topchef
1
Каковы будут преимущества использования JPA, если мне понадобится какая-то особая функция из Hibernate?
Бруно Рейс
22
Важное замечание, которое следует добавить: хотя JPA и JDO отлично поддерживают RDBMS, JDO не зависит от хранилища данных и не ограничивается миром RDBMS. Учитывая тот факт, что в настоящее время NoSQL набирает обороты, было бы разумно рассмотреть возможность использования стандарта постоянства, позволяющего избежать привязки своих приложений к традиционному миру SQL. Приложения JDO могут быть легко развернуты без хранилищ данных RDBMS. Полный список поддерживаемых хранилищ данных можно найти по адресу: datanucleus.org/products/accessplatform/datastores.html
Volksman,
2
@ Голфман, зачем выбирать, основываясь на том, что может случиться? Ничто не помешает вам заняться чем-то другим позже, если вам когда-нибудь понадобится поддержка NoSQL ... KISS
TM.
1
@Bruno - при использовании не-Hibernate специфических частей Hibernate, вы которые с помощью JPA. Очевидно, что преимущество ограничения себя чистым JPA состоит в том, что вы можете легче переключаться на другую реализацию JPA.
Стивен С
69

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

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

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

Вот пример разочарований, которые вы получите с 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 (только RDBMS) и JDO (RDBMS + нет SQL + ODBMS + другие), DataNucleus поддерживает оба, Hibernate ограничивается только JPA.

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

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

Volksman
источник
3
И, как мы все знаем, именно поэтому JDO так широко используется!
Паскаль Тивент
15
Хорошо разрекламированный FUD и астротурфинг, выполненный ключевыми игроками Hibernate в первые дни в отношении JDO, является не чем иным, как нечестным и отвратительным, и, несомненно, оказал некоторое влияние на принятие JDO. В наши дни разработчики знают, что усовершенствование байт-кода не является проблемой, и часто используют его для многих других целей, помимо сохранения. Новая библиотека улучшения байтового кода ASM настолько молниеносна, что даже у вас нет времени, чтобы перевести дух, прежде чем это будет сделано.
Volksman
7
Сбой JDO был предсказан с самого начала ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) и до Hibernate, поэтому вы не можете винить Hibernate в этом. Hibernate / Toplink преуспел там, где игроки Sun и JDO (и их OODBMS) потерпели неудачу, потому что они были лучшими ответами в то время, а не из-за маркетинга и FUD. Период. Кого волнует, что ASM быстро работает сегодня , этого не было 5+ лет назад, когда это было необходимо, и JDO просто проиграл битву. JDO концептуально лучше? Жаль, что не удалось вовремя реализовать победителя (и не вернется из-за JPA).
Паскаль Тивент
2
Чтобы проиллюстрировать мои слова (еще один пост, иллюстрирующий боль, которую люди испытывали во время разработки или почему Hibernate выиграл битву): mail-archive.com/open-jpa-dev@incubator.apache.org/… . Мне кажется очевидным, что рефлексия / cglib была практическим ответом на проблемы людей (и людей не волнует, если API концептуально лучше, если это неудобно использовать), и я не вижу здесь ключевых игроков Hibernate, только пользователей , Итак, в конце я задаюсь вопросом, кто на самом деле распространяет FUD ...
Паскаль Тивент
7
Ну, это, конечно, не похоже на старые времена, когда было бы по крайней мере 17 разных постов про Hibernate FUD (но только с 3 разных IP-адресов. Делайте математику =)).
Volksman
54

Я недавно оценил и выбрал постоянную среду для проекта 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 и решитесь сами.

Том
источник
9
На самом деле, как я уже говорил, я просто высказывал свои впечатления о том, что я обнаружил, пытаясь найти решение. Да, я новичок в Java, почему это так? Вы, с другой стороны, несколько раз писали о том, что вы считаете, что JDO мертва, не предлагая никаких фактов или доказательств, подтверждающих это, и не признавая технические области, в которых JDO явно превосходит все. Очевидно, у вас есть что-то личное против JDO / Datanucleus, и вы используете эти темы как средство для сохранения своей позиции против JDO.
Том
4
Паскаль - вы тут загоняете себя в угол. Я думаю, что вы упускаете из виду раздел Реклама в FAQ. ОП попросил мнения о 2 технологиях. Он призывает тех, кто поддерживает обе стороны, выступить и представить свои конструктивные критические замечания / рекомендации. Для Andy / Datanucleus и других пользователей JDO выделение положительных сторон JDO и защита от критики - это не больше рекламы, чем кто-то другой, кто рекомендует использовать спящий режим.
Том
5
Возможно, вам стоит обратиться к разделу часто задаваемых вопросов, в котором написано «Будьте милы», поскольку ваши посты на эту тему были обвинительными, конфронтационными или грубыми. Ваш первый был саркастический комментарий об улучшении. Во- вторых, разглагольствует о трудностях ранних реализаций и больше не актуален. В-третьих, по-детски издевались и оскорбляли тех, кто предпочитает не использовать СУБД. Четвертым было насмешливое издевательство над кем-то, кто смотрит на тебя иначе. Пятая была атака; называя меня попугаем. Вы считаете это «Быть ​​милым»?
Том
3
Если у вас был ужасный опыт работы с JDO, объясните, что было ужасно, признайте, что это было с более ранней версией, и с тех пор все могло быть улучшено. Вы должны также признать, что у других могут быть разные потребности к вам. То, что вы «удовлетворены» JPA и хотите использовать СУРБД, не означает, что другие это делают. Может быть, в спешке повысить свою репутацию вы потеряли из виду, что эта репутация существует для присуждения? пс. Как разработчик, вы действительно должны быть заинтересованы в благополучии таких проектов, поскольку именно они стимулируют инновации и снижают привязанность к поставщикам.
Том
6
Это будет мой окончательный ответ :) .. 1. Если это не относится к вопросу, зачем поднимать его? 2. Я никогда не ставил под сомнение вашу честность, я говорил, что вы не были добры к другим постерам и противоречили себе. 3. никто не предлагал вам подвести итоги за 8+ лет - но подкрепите свои утверждения фактами и примерами, а не субъективными утверждениями, которые могут оскорбить. 5. Где в этом посте отношение «hibernate / jpa / jboss is evil»? Я не вижу этого. Я вижу только ваши комментарии против JDO.
Том
40

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

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

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

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

oxbow_lakes
источник
4
Это явно выбор анти-объектно-реляционного отображения (ORM), обусловленный большим количеством пользователей и кодовой базой, накопленной со времен ODBC (в начале 90-х годов) (читай в наследство). Нет никаких причин не использовать JDBC (с Spring или без Spring), если вы не решите продолжить и использовать платформу ORM. Подумайте о тех людях, которые однажды решили отказаться от FORTRAN, чтобы использовать C или Pascal.
topchef
23
@grigory - я имею большой опыт тратить дни, пытаясь понять проблемы Hibernate, такие как каскадные обновления / удаления, смехотворно неэффективные структуры запросов и т. д. Решения ORM - это «быстрый выигрыш» для тех, кто недостаточно понимает реляционные базы данных. Таким образом, маловероятно, что знание только Hibernate приведет к хорошему конечному продукту. По моему опыту, в течение жизненного цикла проекта Hibernate (и ORM по расширению) стоит больше времени, чем экономит
oxbow_lakes
8
извините, что у вас был такой плохой опыт работы с Hibernate. Я сам пришел из тяжелой базы данных / SQL / хранимой процедуры / JDBC. Я не могу сказать, что я - новообращенный - у каждой вышеупомянутой технологии есть место. Но для общего назначения 3-уровневое Java-приложение (независимо от его размера) первым выбором является технология ORM - предпочтительно JPA 2. Другие должны рассматриваться на основе таких факторов, как унаследованный код, интеграция, экспертиза, пакетные требования, в режиме реального времени. производительность и т. д., которая может направить (или не направить) подход к другому стеку технологий баз данных.
topchef
3
Я полностью не согласен с приведенным выше определением «быстрого выигрыша» - просто возьмите Hibernate в действии ( stackoverflow.com/questions/96729/… ) (и это JPA 1, а с JPA 2 он становится только лучше), чтобы полностью понять мощь и охват этой технологии есть.
topchef
7
Я провел небольшое исследование, и Spring больше не рекомендует Spring DAO ( static.springsource.org/spring/docs/3.0.x/… ): «Рекомендуемый стиль интеграции заключается в кодировании DAO для простых Hibernate, JPA и JDO API. старый стиль использования шаблонов Spring DAO больше не рекомендуется; "... Это то, что вы рекомендовали? Если так, почему они не рекомендуют это?
User1
23

JDO мертв

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

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

DataNucleus
источник
12
Люди наверняка используют его, о чем свидетельствуют многие пользователи DataNucleus, не говоря уже о Xcalia, Kodo. Вы упускаете основную идею, что JDO и JPA не заполняют один и тот же рынок. JPA является исключительно RDBMS. JDO не зависит от хранилища данных и используется для RDBMS, но также для LDAP, XML, Excel, OODBM и т. Д.
DataNucleus
3
Мне нравится фактор без RDBMS, особенно с ростом популярности решений без RDBMS, это большое дело. Это означает, что если JPA развивается недостаточно быстро, наличие «более открытой» и гибкой альтернативы (JDO) означает, что популярность JPA будет снижаться из-за необходимости. Не берите в голову технические аргументы, что JDO является более полным, превосходным, зрелым или чем-то еще - это не будет вопросом предпочтения . Имеет смысл, что поставщики RDBMS ведут себя подозрительно - дни доминирования RDBMS на рынке могут подходить к концу.
Маниус
Мы все еще используем JDO / DataNucleus в 2019 году! Теперь он до версии 5.x и все еще опережает Hibernate по производительности для разработчиков и производительности во время выполнения. Недавно мне пришлось проконсультироваться с большим веб-приложением, использующим Hibernate, и мне напомнили о боли, которую я испытывал, когда много лет назад был активным пользователем и промоутером HIbernate. Руководитель группы не поверил мне, когда я сказал ей, что ее поле BLOB всегда охотно доставался, хотя был помечен как ленивый. Полное отсутствие знаний «под капотом» у «опытного» самопровозглашенного эксперта Hibernate было печально, но ожидаемо.
Volksman
10

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


источник
8

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

тапи
источник
6
+1 за DataNucleus, а не за ответ.
WolfmanDragon
8

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

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

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

Volksman
источник
1
Или вы используете другую (прекрасную) реализацию с гораздо большим и, следовательно, более отзывчивым сообществом. Да, некоторые люди заботятся об этом тоже.
Паскаль Тивент
1
А вы говорите о FUD> :) Забавно.
Паскаль Тивент
2
Ваш комментарий предполагает, что я не использовал ни Hibernate, ни JDO.
Volksman
2
Похоже, в этой теме очень много ссылок от пары людей о том, насколько хорош DataNucleus. Пожалуйста, не используйте это место в качестве вашей рекламной платформы.
ТМ.
3
Ничего удивительного в том, что Гольфман многократно вставляет одни и те же отчаянные маркетинговые материалы в каждый поток, включающий JPA или DataNucleus (который он использует с 1996 года , еще до того , как он появился !).
Паскаль Тивент
2

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

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

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

Шон Макколифф
источник
1
Насколько я могу судить, JPOX сменил имя на DataNucleus (и с тех пор выпускал его).
Donal Fellows
2
Думаю, вы действительно обнаружите, что в DataNucleus меньше открытых ошибок, чем в других программах, на которые вы ссылаетесь. Думаю, вы также обнаружите, что разработка DataNucleus сокращает количество ошибок быстрее, чем это другое программное обеспечение.
DataNucleus
1

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

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

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

Торбен Вестерагер
источник