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

Ответ 1

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

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

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

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

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

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

На самом деле вам, вероятно, потребуется компромисс, насколько вас беспокоит участие поставщика в сравнении с тем, насколько вам нужны эти расширения для конкретного поставщика.

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

Ответ 2

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

Другим преимуществом JDO/DataNucleus по сравнению с hibernate является то, что он не имеет всех служебных данных отражения времени выполнения и более эффективен с точки зрения памяти, поскольку он использует увеличение времени байт-кода (возможно, добавьте 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 (только RDBMS) и JDO (RDBMS + Нет SQL + ODBMSes + другие), DataNucleus поддерживает оба варианта, Hibernate ограничивается только JPA.

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

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

Ответ 3

Недавно я оценил и выбрал структуру персистентности для проекта java, и мои выводы заключаются в следующем:

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

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

и поддержка в пользу JPA в первую очередь:

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

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

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

В отношении более популярной JPA, похоже, что это объясняется частично из-за поддержки поставщиков RDBMS, а не с технической точки зрения. (Звучит как VHS/Betamax для меня).

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

JDO мертв

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

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

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

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