Какой постоянный поставщик EJB 3 мне следует использовать? - PullRequest
3 голосов
/ 19 сентября 2008

Я использую EJB 3 в довольно большом проекте J2EE, по умолчанию Netbeans устанавливает постоянный провайдер для компонентов управления данными в TopLink. Существует возможность изменить поставщика на один из следующих или даже добавить новую постоянную библиотеку:

  • Hibernate
  • KODO
  • OpenJPA

Каким провайдером персистентности вы предпочитаете пользоваться? Каковы преимущества использования другого поставщика?

Хотя TopLink кажется хорошим, я не могу найти много хорошей документации о том, как управлять кэшированием и т. Д. Любая помощь будет высоко ценится.

Ответы [ 6 ]

7 голосов
/ 19 сентября 2008

Есть только два JPA-провайдера, которых я хотел бы использовать:

Если вы хотите придерживаться стандартного JPA, я бы использовал EclipseLink. Принимая во внимание, что Toplink Essentials является эталонной реализацией JPA 1.0, EclipseLink в основном унаследовал код TopLink Essentials и будет эталонной реализацией JPA 2.0 (и поставляется вместе с Glassfish V3, когда она выйдет; ожидается около JavaOne в мае 2009 г.) TopLink Essentials был несколько урезанной версией коммерческого продукта Oracle TopLink, но EclipseLink в основном имеет все функции, которые есть у TopLink.

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

Hibernate, конечно, также поддерживает стандарт JPA. Самое большое преимущество Hibernate в том, что если у вас есть вопрос о том, как он работает, поиск в Google, скорее всего, найдет вам ответ.

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

2 голосов
/ 19 сентября 2008

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

Несколько маленьких игрушечных проектов, которые я пробовал с TopLink Essentials, тоже работали довольно хорошо, но я никогда не занимался кэшированием или чем-то, что требовало бы документации конкретного поставщика. В целом, я думаю, что поддержка сообщества для этого меньше, поэтому я использую Hibernate.

2 голосов
/ 19 сентября 2008

Я настоятельно рекомендую Hibernate по следующим причинам:

  • Наиболее широко используемый и уважаемый уровень персистентности с открытым исходным кодом в мире Java; огромное активное сообщество и большое количество приложений для критически важных приложений.
  • Вы вообще не привязываетесь к J2EE или конкретному поставщику, если хотите пойти другим путем с другим приложением, таким как Spring и т. Д., Поскольку Hibernate по-прежнему будет играть хорошо.
1 голос
/ 19 сентября 2008

Я использую Hibernate. Это очень зрелый и работает очень хорошо. Лично я не использовал никаких других, но я знаю, что Hibernate является одним из наиболее полнофункциональных JPA-провайдеров. Кроме того, так как многие люди используют его, почти каждую проблему, с которой я столкнулся, я могу быстро найти решение, немного погуглив.

0 голосов
/ 21 марта 2009

DataNucleus http://www.datanucleus.org также полностью совместимый поставщик JPA, с JPA1 и некоторыми функциями предварительного просмотра JPA2

0 голосов
/ 20 сентября 2008

Недавно я работал над крупным корпоративным приложением, созданным на основе инфраструктуры Kodo JPA. SQL, производимые Kodo, обычно не очень масштабируемы с большим количеством данных. По моему мнению, это вызвало слишком много запросов с внешними объединениями. Учитывая, сколько отображений нам пришлось изменить при попытке масштабировать кодо, я бы не рекомендовал использовать его для больших корпоративных приложений. Даже представители Oracle, с которыми мы говорили, пытаются отучить клиентов от кодо на TopLink. Oracle может отказаться от кодо в будущем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...