Hibernate vs JPA vs JDO-плюсы и минусы каждого? [закрытый]
Я знаком с ORM как концепцией, и я даже использовал nHibernate несколько лет назад для проекта .NET; однако я не поспевал за темой ORM в Java и не имел возможности использовать любой из этих инструментов.
но теперь у меня может быть возможность начать использовать некоторые инструменты ORM для одного из наших приложений, пытаясь отойти от серии устаревших веб-сервисов.
Мне трудно сказать разницу между спецификацией JPA, что вы получаете с самой библиотекой Hibernate и тем, что может предложить JDO.
Итак, я понимаю, что этот вопрос немного открытый, но я надеялся получить некоторые мнения:
- каковы плюсы и минусы каждого?
- что бы вы предложили для нового проекта?
- существуют ли определенные условия, когда имело бы смысл использовать один фреймворк против другого?
11 ответов
некоторые замечания:
- JDO и JPA являются спецификациями, а не реализациями.
- идея в том, что вы можете поменять реализации JPA, если вы ограничиваете свой код только стандартным JPA. (То же самое для JDO.)
- Hibernate может использоваться как одна из таких реализаций JPA.
- однако Hibernate предоставляет собственный API с функциями выше и за пределами JPA.
IMO, я бы рекомендовал Зимовать.
были некоторые комментарии / вопросы о том, что вы должны делать, если вы нужно для использования функций Hibernate. Есть много способов посмотреть на это, но мой совет был бы:
Если вас не беспокоит перспектива подключения поставщика, сделайте свой выбор между Hibernate и другими реализациями JPA и JDO в том числе различные расширения конкретного поставщика в вашем решении изготовление.
Если вас беспокоит перспектива подключения поставщика, и вы не можете использовать JPA, не прибегая к конкретным расширениям поставщика, тогда не используйте JPA. (То же самое для JDO).
на самом деле, вам, вероятно, потребуется компромисс сколько вас беспокоит привязка поставщика против сколько вам нужны эти расширения поставщика.
есть и другие факторы, например, насколько хорошо вы сотрудники знают соответствующие технологии, сколько будет стоить продукция при лицензировании и в чью историю вы верите о том, что произойдет в будущем для JDO и JPA.
убедитесь, что вы оцениваете реализацию DataNucleus JDO. Мы начали с Hibernate, потому что он оказался настолько популярным, но довольно скоро понял, что это не 100% прозрачное решение для сохранения. Есть слишком много предостережений, и документация полна "если у вас есть эта ситуация, то вы должны написать свой код, как это", что отняло удовольствие от свободного моделирования и кодирования, как мы хотим. JDO В имеет никогда заставил меня настроить мой код или мою модель, чтобы получить его "правильно работать". Я могу просто создавать и кодировать простые POJOs, как если бы я собирался использовать их только "в памяти", но я могу сохранять их прозрачно.
другое преимущество JDO в/DataNucleus за гибернация что это не обязательно все время выполнения отражения накладных расходов и экономия памяти, поскольку он использует время сборки байт-код аксессуара (возможно добавить 1 сек до построения время для большого проекта), а не спящий режим по времени отражения работает прокси узор.
еще одна вещь, которую вы можете найти раздражающим с 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) vs JDO (RDBMS + No SQL + ODBMSes + others), DataNucleus поддерживает оба, Hibernate ограничен только JPA.
производительность обновлений БД Hibernate
еще одна проблема, которую следует учитывать при выборе ORM, - это эффективность механизма грязной проверки-это становится очень важным, когда ему нужно построить SQL для обновления объектов, которые имеют изменено в текущей транзакции, особенно когда много объектов. Существует подробное техническое описание механизма грязной проверки Hibernate в этом ответе SO: JPA с HIBERNATE вставить очень медленно
недавно я оценил и выбрал структуру персистентности для проекта java, и мои выводы следующие:
Я вижу, что поддержка в пользу JDO в первую очередь:
- вы можете использовать источники данных, отличные от sql, db4o, hbase, ldap, bigtable, couchdb (плагины для cassandra) и т. д.
- вы можете легко переключиться с sql на источник данных не sql и наоборот.
- нет прокси-объектов и, следовательно, меньше боли с с уважением к реализациям hashcode() и equals ()
- больше POJO и, следовательно, меньше обходных путей требуется
- поддерживает больше типов отношений и полей
и поддержка в пользу JPA в первую очередь:
- более популярным
- JDO в Умер
- не использует улучшение байт-кода
Я вижу много сообщений pro-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 и не слишком беспокоиться о схеме DB, а затем, когда схема стабилизируется для развертывания в базе данных. Я также уверен, что позже я мог бы развернуть все/часть моего приложения в GAE или воспользоваться распределенным хранилищем/картой-уменьшить a la hbase /hadoop / cassandra без слишком большого рефакторинга.
Я нашел начальное препятствие для начала работы с Datanucleus немного сложным - документация на сайте datanucleus немного трудно попасть - учебники не так легко, как хотелось бы. Сказав это, более подробная документация по API и сопоставлению очень хороша, как только вы пройдете начальную кривую обучения.
ответ: это зависит от того, что вы хотите. Я бы предпочел более чистый код, без блокировки поставщика,более pojo-ориентированный, более популярные стихи NoSQL.
Если вы хотите теплое суетливое чувство, что вы делаем то же самое, что и большинство других разработчиков/овец, выбираем JPA/hibernate. Если вы хотите вести в своей области, тест-драйв JDO / Datanucleus и сделать свой собственный ум.
что бы вы предложили для нового проекта?
Я бы предложил ни! Использовать Spring Дао JdbcTemplate вместе с StoredProcedure, RowMapper и .
мой личный опыт работы с Hibernate заключается в том, что время, сэкономленное заранее, более чем компенсируется бесконечными днями, которые вы проведете, пытаясь понять и отладить такие проблемы, как неожиданное каскадное поведение обновления.
если вы используете реляционную БД, то чем ближе ваш код к нему, тем больше у вас контроля. Слой DAO весны позволяет точному управлению слоя отображения, пока извлекающ потребность для кода boilerplate. Кроме того, он интегрируется в уровень транзакций Spring, что означает, что вы можете очень легко добавить (через AOP) сложное транзакционное поведение без этого вторжения в ваш код (конечно, вы получаете это с Hibernate тоже).
JDO в Умер
JDO на самом деле не мертв, поэтому, пожалуйста, проверьте свои факты. JDO 2.2 был выпущен в октябре 2008 года JDO 2.3 находится в стадии разработки.
это разработано открыто, под Apache. Больше выпусков, чем у JPA, и его спецификация ORM по-прежнему опережает даже предлагаемые функции JPA2
JDO имеет расширенные функции, чем JPA see http://db.apache.org/jdo/jdo_v_jpa.html
Я использую JPA (реализация OpenJPA от Apache, которая основана на кодовой базе KODO JDO, которая старше 5 лет и очень быстрая/надежная). ИМХО любой, кто говорит вам обойти спецификации, дает вам плохой совет. Я потратил время и был определенно вознагражден. С помощью JDO или JPA вы можете изменить поставщиков с минимальными изменениями (JPA имеет отображение orm, поэтому мы говорим меньше, чем за день, чтобы возможно изменить поставщиков). Если у вас есть 100+ таблиц, как я это делаю, это огромно. Плюс вы получаете built0in кэширование с помощью кластерных выселений кэша и все это хорошо. SQL/Jdbc отлично подходит для высокопроизводительных запросов, но прозрачная персистентность намного превосходит для написания алгоритмов и процедур ввода данных. У меня есть только около 16 SQL-запросов во всей моей системе (50k+ строк кода).
любой, кто говорит, что JDO мертв, является астротурфинг FUD monger, и они это знают.
JDO жив и здоров. Спецификация по-прежнему более мощная, зрелая и продвинутая, чем гораздо более молодая и ограниченная JPA.
Если вы хотите ограничить себя только тем, что доступно в стандарте JPA, вы можете написать JPA и использовать DataNucleus как высокопроизводительную, более прозрачную реализацию персистентности, чем другие реализации JPA. Конечно, DataNucleus также реализует стандарт JDO, если вы хотите гибкость и эффективность моделирования, которое приносит JDO.
Я сам занимался этим и не могу найти сильной разницы между ними. Я думаю, что большой выбор - это то, в какой реализации вы используете. Для себя я рассматривал DataNucleus платформа, поскольку это агностическая реализация хранилища данных обоих.
Я использовал Hibernate (реализация JPA) и JPOX (реализация JDO) в том же проекте. JPOX работал нормально, но столкнулся с ошибками довольно быстро, там, где некоторые функции языка Java 5 он не поддерживал в то время. У него были проблемы с хорошей игрой с транзакциями XA. Я создавал схему базы данных из объектов JDO. Он хотел подключиться к базе данных каждый раз, когда это раздражает, если ваше соединение Oracle не работает.
затем мы перешли к Зимовать. Некоторое время мы просто играли с использованием чистого JPA, но нам нужно было использовать некоторые специфические функции Hibernate для отображения. Запуск одного и того же кода в нескольких базах данных очень прост. Hibernate, похоже, агрессивно кэширует объекты или просто иногда имеет странное поведение кэширования. Есть несколько конструкций DDL Hibernate не может обрабатывать и поэтому они определены в дополнительном файле, который запускается для инициализации базы данных. Когда я столкнулся с проблемой Hibernate, часто многие люди, которые столкнулись с той же проблемой, которая облегчает поиск решений. Наконец, Hibernate кажется хорошо спроектированным и надежным.
некоторые другие респонденты предложили просто использовать SQL. Реальный случай использования убийцы для реляционного отображения объектов-это тестирование и разработка. Базы данных, построенные для обработки больших объемов данных, как правило, дороги или их трудно установить. Их трудно проверить. Есть много в памяти Java базы данных, которые можно использовать для тестирования, но обычно бесполезны для производства. Возможность использования реальной, но ограниченной базы данных повысит производительность разработки и надежность кода.
Я сделал образец WebApp в мае 2012 года, который использует JDO 3.0 & DataNucleus 3.0-посмотрите, насколько он чист: https://github.com/TorbenVesterager/BadAssWebApp
хорошо, может быть, это немного слишком чисто, потому что я использую POJOs как для базы данных, так и для клиента JSON, но это весело :)
PS: содержит несколько аннотаций SuppressWarnings (разработанных в IntelliJ 11)