Я хочу разработать свой проект в 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 не придаст этому большого эффекта. Это имеет смысл, поскольку хранилище данных GAE не является реляционной базой данных. Некоторые функции JPA не работают с большими таблицами, такими как запросы к агрегации, входящие запросы, принадлежащие отношениям "многие ко многим". BTW, 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: 68ms
JDO: 378 мс
Java Native: 30ms
В гонке между JDO против JPA я могу согласиться только с плакатами datanucleus.
Прежде всего, а также, что самое главное, плакаты датануклеуса знают, что они делают. Они все-таки развивают постоянную библиотеку и знакомы с моделями данных, отличными от реляционных, например. Большой стол. Я уверен, что id разработчика для спящего режима был здесь, он сказал бы: "все наши предположения при построении наших основных библиотек тесно связаны с реляционной моделью, спящий режим не оптимизирован для GAE".
Во-вторых, JPA, несомненно, является более широкое применение, являясь частью официального стека Java EE помогает немного, но это не обязательно означает, что это лучше. На самом деле JDO, если вы читаете об этом, соответствует более высокому уровню абстракции, чем JPA. JPA тесно связана с моделью данных РСУБД.
С точки зрения программирования использование JDO API намного лучше, потому что вы концептуально компрометируете намного меньше. Теоретически вы можете переключиться на любую модель данных вашего желания, если поставщик, которого вы используете, поддерживает базовую базу данных. (На практике вы редко достигаете такого высокого уровня прозрачности, потому что вы обнаружите, что задаете первичные ключи объекта GAE, и вы будете привязываться к определенному поставщику базы данных, например Google). все равно будет легче мигрировать.
В-третьих, вы можете использовать Hibernate, Eclipse Link и даже spring с GAE. Google, похоже, прилагает большие усилия, чтобы позволить вам использовать рамки, которые вы используете для создания своих приложений. Но то, что люди понимают, когда они создают свои приложения GAE, как будто они работают на СУБД, это то, что они медленны. spring на GAE SLOW. Вы можете использовать Google IO-видео в этом разделе, чтобы убедиться, что это правда.
Кроме того, соблюдение стандартов - это хорошая разумная вещь, в принципе я приветствую. С другой стороны, JPA, являющаяся частью стека Java EE, заставляет людей время от времени терять свое представление об опциях. Поймите, если хотите, что Java Server Faces также является частью стека Java EE. И это невероятно простое решение для разработки веб-графического интерфейса. Но в конце концов, почему люди, умные люди, если можно так сказать, отклоняются от этого стандарта и вместо этого используют GWT?
Во всем этом, я должен сказать, что есть очень важная вещь для JPA. Это Guice и его удобная поддержка JPA. Кажется, что Google не был таким умным, как обычно, в этом вопросе, и он доволен, пока он не поддерживает JDO. Я все еще думаю, что они могут себе это позволить, и, в конце концов, Guice также поглотит JDO... или, может быть, нет.
Go JDO. Даже если у вас нет опыта в этом, его нетрудно подобрать, и у вас будет новый навык под вашим поясом!
То, что мне кажется ужасным в использовании JDO на момент написания этого, заключается в том, что единственным поставщиком реализации является Datanucleus, а недостатками этого является отсутствие конкуренции, что приводит к многочисленным проблемам, таким как:
extensionsStackOverflowЯ всегда надеюсь, что кто-то начнет реализацию самой спецификации JDO, возможно, тогда они предложит нечто большее и, надеюсь, больше бесплатное внимание к сообществу и не всегда беспокоит заплатил за поддержку, не сказав, что Datanucleus авторы только заботятся о коммерческой поддержке, но я просто говорю.
Я лично считаю, что авторы Datanucleus не имеют никаких обязательств перед самим Datanucleus или сообществом. Они могут отказаться от всего проекта в любое время, и никто не может судить о нем, его усилиях и их собственном имуществе. Но вы должны знать, что вы получаете. Видите ли, когда один из нас разработчики ищут фреймворк для использования, вы не можете наказывать или командовать автором фреймворка, но, с другой стороны, вам нужна ваша работа! Если бы у вас было время написать эту фреймворку, почему бы вам искать ее в первую очередь?!
С другой стороны, JDO сам имеет некоторые сложности, такие как жизненный цикл объектов и вещи, которые не очень интуитивно понятны и распространены (я думаю).
Изменить: теперь я также знаю, что JPA применяет механизм жизненного цикла объекта, поэтому он выглядит неизбежным, чтобы иметь дело с состояниями жизненного цикла с сохраненными сущностями, если вы хотите использовать стандартный API ORM (т.е. JPA или JDO)
Что мне больше всего нравится в JDO, так это способность работать с ЛЮБОЙ системой управления базами данных без особых усилий.
GAE/J планируется добавить MYSQL до конца года.
JPA - это путь, по которому он, как представляется, вытесняется как стандартизованный API и недавно получил импульс в EJB3.0. JDO, похоже, потерял пар.
Ни!
Используйте Objectify, потому что дешевле (используйте меньше ресурсов) и быстрее. FYI: 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);