JDO против JPA для Java в Google App Engine

https://stackoverflow.com/questions/1418219

07-07-2019
|

Вопрос

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

Спасибо.

Решение

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

Другие советы

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

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

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

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

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

Для справки, это 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 : 30 мс

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

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

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

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

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

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

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

Иди, Джойдо.Даже если у вас нет опыта в этом, освоить его несложно, и у вас за плечами появится новый навык!

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

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

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

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

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

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

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

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

JPA - это правильный путь, поскольку он, похоже, продвигается как стандартизированный API и недавно набрал обороты в EJB3.0..JDO, похоже, потерял терпение.

Ни то, ни другое!

Используйте Objectify, потому что это дешевле (использует меньше ресурсов) и работает быстрее.К ТВОЕМУ СВЕДЕНИЮ: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify - это Java API для доступа к данным, специально разработанный для Хранилища данных Google App Engine.Он занимает "золотую середину".;проще в использовании и прозрачнее, чем JDO или JPA, но значительно более удобный, чем низкоуровневый API.Объективировать предназначено, чтобы сделать новички сразу же производительной, но также выставить на полную мощность Хранилище GAE.

Objectify позволяет сохранять, извлекать, удалять и запрашивать ваши собственные типизированные объекты.

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow