Я хочу развивать свой проект на Google App Engine с помощью Struts2. Для базы данных у меня есть два варианта JPA и JDO. Не могли бы вы предложить мне это? Оба они для меня новые, и мне нужно их изучить. Так что я сосредоточусь на одном после ваших ответов.
Благодарю.
Ответы:
JPA - это стандарт настойчивости Sun, JDO, IMHO, умирает (на самом деле, он мертв, но все еще движется). Другими словами, JPA кажется более выгодным вложением в долгосрочной перспективе. Так что я бы выбрал JPA, если бы оба были для меня новичком.
В группе Google GAE / J есть несколько сообщений об этом. Я бы поискал там и посмотрел на мнения людей. Вы получите совершенно иное сообщение, чем мнения, высказанные выше. Также обратите внимание на тот факт, что 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 не дала ему большой импульс. Это имеет смысл, потому что хранилище данных 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 - это производительность.
Например, добавьте 10 сущностей
Python: 68 мс
JDO: 378 мс
Собственный Java: 30 мс
В гонке между JDO и JPA я могу согласиться только с плакатами datanucleus.
Прежде всего, а также самое главное, плакаты datanucleus знают, что они делают. В конце концов, они разрабатывают постоянную библиотеку и знакомы с моделями данных, отличными от реляционных, например, Big Table. Я уверен, что id разработчик для спящего режима был здесь, он сказал бы: «все наши предположения при создании наших основных библиотек тесно связаны с реляционной моделью, спящий режим не оптимизирован для GAE».
Во-вторых, JPA, несомненно, пользуется более широким распространением, будучи частью официального стека Java EE, немного помогает, но это не обязательно означает, что он лучше. Фактически, JDO, если вы читаете об этом, соответствует более высокому уровню абстракции, чем JPA. JPA тесно связана с моделью данных СУБД.
С точки зрения программирования использование JDO API - гораздо лучший вариант, потому что концептуально вы гораздо меньше рискуете. Теоретически вы можете переключиться на любую модель данных по вашему желанию при условии, что поставщик, который вы используете, поддерживает базовую базу данных. (На практике вы редко достигаете такого высокого уровня прозрачности, потому что вы обнаружите, что устанавливаете свои первичные ключи для объекта 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, ... а может и нет.
Что я считаю ужасным в использовании JDOна момент написания этой статьи, так это то, что это единственный поставщик реализации, Datanucleusи недостатком этого является отсутствие конкуренции, которая приводит к многочисленным проблемам, таким как:
extensionsStackOverflowЯ всегда надеюсь, что кто-то сам приступит к реализации 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 - это API доступа к данным Java, специально разработанный для хранилища данных Google App Engine. Он занимает «золотую середину»; проще в использовании и прозрачнее, чем JDO или JPA, но значительно удобнее, чем API низкого уровня. Objectify призван сделать новичков продуктивными, а также раскрыть всю мощь хранилища данных 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);