JDO против JPA для Java в Google App Engine - PullRequest
81 голосов
/ 13 сентября 2009

Я хочу разработать свой проект на Google App Engine с Struts2. Для базы данных у меня есть два варианта JPA и JDO. Ребята, пожалуйста, предложите мне это? Оба для меня новы, и мне нужно учить их. Поэтому я сосредоточусь на одном после ваших ответов.

Спасибо.

Ответы [ 12 ]

32 голосов
/ 14 сентября 2009

В группе Google GAE / J есть несколько сообщений на эту тему. Я бы сделал там поиск и посмотрел бы на мнение людей. Вы получите совершенно другое сообщение с мнением, высказанным выше. Также обратите внимание на то, что BigTable не является RDBMS. Используйте правильный инструмент для работы

32 голосов
/ 13 сентября 2009

JPA - это стандарт настойчивости Sun, JDO умирает (на самом деле, он мертв, но все еще движется) Другими словами, JPA кажется более выгодной инвестицией в долгосрочной перспективе. Думаю, я бы выбрал JPA, если бы оба были для меня новыми.

24 голосов
/ 13 октября 2009

Только что видел это сравнение между JPA и JDO самими DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Откровение.

16 голосов
/ 28 января 2010

Я счастливый пользователь JDO. Продолжайте в том же духе, ребята.

12 голосов
/ 10 февраля 2011

Люди, утверждающие, что JDO мертва, не без заслуг. Вот что я прочитал в книге Pro EJB 3 API сохраняемости Java: «Вскоре после этого Sun объявила, что JDO будет переведен в режим обслуживания спецификации и что API сохраняемости Java будет опираться как на JDO, так и на других поставщиков сохраняемости и станет единственным поддерживаемым стандарт, идущий вперед. Автор Майк Кейт является лидером совместной спецификации EJB3. Конечно, он большой сторонник JPA, но я сомневаюсь, что он достаточно предвзят, чтобы лгать.

Это правда, что, когда книга была опубликована, большинство крупных поставщиков объединились за JPA, а не JDO, хотя JDO обладает более продвинутыми техническими возможностями, чем JPA. Это неудивительно, потому что крупные игроки в мире EE, такие как IBM / Oracle, также являются крупными поставщиками СУБД. Больше клиентов используют RDMBS, чем не RDMBS в своих проектах. JDO умирал до тех пор, пока GAE не дало ему большой импульс. Это имеет смысл, поскольку хранилище данных GAE не является реляционной базой данных. Некоторые функции JPA не работают с такими таблицами, как запросы на агрегацию, запросы на присоединение, принадлежащие отношения «многие ко многим». Кстати, GAE поддерживает JDO 2.3, а поддерживает только JPA 1.0. Я рекомендую JDO, если GAE - ваша целевая облачная платформа.

11 голосов
/ 01 сентября 2011

Кстати, это Google App Engine (GAE), поэтому мы играем по правилам Google, а не по правилам Oracle / Sun.

Под ним JPA не подходит для GAE, он нестабилен и работает не так, как ожидалось. Ни Google не хочет поддерживать это, но минимальный.

А с другой стороны, JDO довольно стабилен в GAE, и он (в некоторой степени) хорошо задокументирован Google.

Однако Google не рекомендует ни один из них.

http://code.google.com/appengine/docs/java/datastore/overview.html

Низкоуровневый API обеспечит наилучшую производительность, а GAE - все о производительности.

http://gaejava.appspot.com/

Например, добавить 10 сущностей

Python: 68 мс

JDO: 378мс

Java Native: 30 мс

9 голосов
/ 14 июля 2012

В гонке между JDO против JPA я могу согласиться только с постерами с датануклеусом.

Прежде всего, а также, самое главное, плакаты datanucleus знают, что они делают. В конце концов, они разрабатывают постоянную библиотеку и знакомы с моделями данных, отличными от реляционных, например, Большой стол. Я уверен, что если бы здесь был разработчик hibernate, он сказал бы: «все наши предположения при создании наших базовых библиотек тесно связаны с реляционной моделью, hibernate не оптимизирован для GAE».

Во-вторых, JPA, несомненно, является более широкое применение, являясь частью официального стека Java EE помогает немного, но это не обязательно означает, что это лучше. Фактически, JDO, если вы читаете об этом, соответствует более высокому уровню абстракции, чем JPA. JPA тесно связан с моделью данных RDBMS.

С точки зрения программирования, использование API-интерфейсов JDO - намного лучший вариант, потому что вы концептуально компрометируете намного меньше. Теоретически вы можете переключиться на любую модель данных по вашему желанию, если поставщик, которого вы используете, поддерживает базовую базу данных. (На практике вы редко достигаете такого высокого уровня прозрачности, потому что вы обнаружите, что устанавливаете свои первичные ключи для объекта GAE, и вы будете привязывать себя к конкретному поставщику базы данных, например, Google). миграция все равно будет проще.

В-третьих, вы можете использовать Hibernate, Eclipse Link и даже Spring с GAE. Похоже, что Google приложил большие усилия, чтобы позволить вам использовать фреймворки, на которых вы строили свои приложения. Но то, что люди понимают, когда они создают свои приложения GAE, как если бы они работали на СУБД, это то, что они работают медленно. Весна на GAE МЕДЛЕННАЯ. Вы можете посмотреть видео Google IO по этой теме, чтобы убедиться, что это правда.

Кроме того, придерживаться стандартов - разумная вещь, в принципе, я аплодирую. С другой стороны, JPA, являющаяся частью стека Java EE, иногда заставляет людей терять представление о возможностях. Поймите, если хотите, что Java Server Faces также является частью стека Java EE. И это невероятно аккуратное решение для разработки веб-интерфейса. Но в конце концов, почему люди, более умные люди, если можно так выразиться, отклоняются от этого стандарта и вместо этого используют GWT?

Во всем этом я должен сказать, что в JPA есть одна очень важная вещь. Это Guice и его удобная поддержка JPA. Похоже, что Google не был таким умным, как обычно, в этом вопросе и доволен, пока что не поддерживает JDO. Я все еще думаю, что они могут себе это позволить, и в конечном итоге Guice также поглотит JDO ... или, возможно, нет.

6 голосов
/ 28 января 2013

То, что я считаю ужасным при использовании JDO на момент написания, это то, что единственным поставщиком реализации является Datanucleus, и недостатками этого является отсутствие конкуренции, что приводит к многочисленным проблемам, таким как:

  1. Не очень подробная документация о некоторых аспектах, таких как extensions
  2. Вы обычно получаете саркастические ответы от авторов, такие как (Вы проверили журналы? Может быть, есть причина для их получения) и раздражающие ответы, подобные этому
  3. Вы не получите ответ на свой вопрос в течение полезного промежутка времени, иногда, если вы получите ответ менее чем за 7 дней, вам следует считать себя счастливчиком, даже здесь, на StackOverflow

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

Я лично считаю, что Datanucleus авторы не имеют никаких обязательств ни перед Datanucleus, ни перед его сообществом. Они могут отказаться от всего проекта в любое время, и никто не может судить их за это, это их усилия и их собственная собственность. Но вы должны знать, во что вы ввязываетесь. Видите ли, когда один из нас, разработчиков, ищет платформу для использования, вы не можете наказать или дать команду автору фреймворка, но, с другой стороны, вам нужна ваша работа! Если у вас было время написать этот фреймворк, зачем вам его искать?!

С другой стороны, JDO сам по себе имеет некоторые сложности, такие как жизненный цикл объектов и прочее, что не очень интуитивно и распространено (я думаю).

Редактировать: Теперь я также знаю, что JPA применяет механизм жизненного цикла объекта, поэтому похоже, что неизбежно иметь дело с состояниями жизненного цикла постоянных сущностей, если вы хотите использовать стандартный ORM API (то есть JPA или * 1030). *)

Что мне больше всего нравится в JDO, так это возможность работать с ЛЮБОЙ системой управления базами данных без значительных усилий.

6 голосов
/ 15 июля 2010

Go JDO. Даже если у вас нет опыта, это не сложно поднять, и у вас будет новый навык под вашим поясом!

3 голосов
/ 18 августа 2010

GAE / J планируется добавить MYSQL до конца года.

...