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

Я знаком с 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, это то, что у вас есть ссылка на то, что вы считаете объектом - это часто «прокси» для объекта. Без преимущества улучшения байт-кода шаблон прокси-сервера необходим для разрешения загрузки по требованию (то есть, не тяните весь объектный граф, когда вы тянете объект верхнего уровня). Будьте готовы переопределить 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 вставляет очень медленно

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

Если вы используете реляционную БД, то чем ближе ваш код к ней, тем больше у вас контроля. Слой Spring DAO позволяет точно контролировать слой отображения, одновременно устраняя необходимость в шаблонном коде. Кроме того, он интегрируется в уровень транзакций 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 есть сопоставление форм, поэтому мы говорим меньше дня, чтобы, возможно, сменить поставщиков). Если у вас есть более 100 столов, как у меня, это огромно. Кроме того, вы получаете встроенное кеширование с удалением кеша по кластеру и все это хорошо. SQL / Jdbc хорош для высокопроизводительных запросов, но прозрачное постоянство намного лучше для написания ваших алгоритмов и процедур ввода данных. У меня всего около 16 запросов SQL во всей моей системе (50 000 строк кода).

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

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

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

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

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

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

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

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

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

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