Доступ к хранилищу данных GAE: используйте JDO, JPA или низкоуровневый API? - PullRequest
4 голосов
/ 20 ноября 2010

Какие-либо рекомендации о том, как лучше всего получить доступ к хранилищу данных Google App Engine? Через JDO, JPA или нативный API?

Очевидные преимущества JDO / JPA - это переносимость на другие механизмы баз данных, но кроме этого, есть ли какая-либо причина не работать напрямую с API Datastore?

Ответы [ 3 ]

7 голосов
/ 20 ноября 2010

Я не знаю много о JPA, но я пошел с JDO, и если вы новичок в этом, я могу сказать, что у него довольно крутая кривая обучения и много посторонних вещей, которые не относятся к GAE , Вы выигрываете принадлежащих отношений, , которые позволяют вам иметь классы с реальными ссылками друг на друга, а не просто с идентификаторами хранилища данных. Есть также несколько полезных вещей, которые JDO делает с помощью аннотаций, таких как аннотация @Element (зависимый = "истина"), которая экономит вам немного времени, поскольку позволяет удалять родительский объект, а JDO удаляет все его дочерние элементы. В общем, документы GAE упускают множество вещей, которые вам необходимо знать, чтобы эффективно использовать JDO, поэтому я бы сказал, что крайне важно прочитать документы datanucleus и уделить особое внимание группам извлечения.

Вы также можете найти большую коллекцию кратких примеров для JDO и JPA, которые рассматривают почти все возможные сценарии здесь.

Наконец, я хотел бы взглянуть на Objectify и Twig, две, по-видимому, популярные альтернативные среды, которые были упомянуты в вопросе, который я задал , когда я также пытался принять это решение.

Что касается переносимости в другие базы данных, я думаю, что беспокоиться о переносимости в GAE немного ошибочно. Как бы Google не хотел, чтобы мы думали, что код GAE является переносимым, я думаю, что это несбыточная мечта. Вы в конечном итоге будете писать код для целевого набора API, который предлагает Google, набора, который вы, вероятно, не увидите больше нигде, а также кодировать вокруг множества ограничений и особенностей GAE, поэтому я бы забыл о переносимости как факторе для решения API доступа к данным. На самом деле, если бы я мог переделать свое решение по этому вопросу, я думаю, что я бы использовал инфраструктуру доступа к данным, созданную специально для GAE, такую ​​как objectify.

6 голосов
/ 21 ноября 2010

Низкоуровневый API хранилища данных предназначен не для непосредственного использования, а скорее для предоставления API-интерфейса для других сред, взаимодействующих с хранилищем данных.

Этот пакет содержит низкоуровневый API дляхранилище данных, предназначенное в основном для авторов фреймворка.Авторам приложений следует рассмотреть возможность использования предоставленных интерфейсов JDO или JPA для хранилища данных.

( source )

Одна такая структура - Objectify , гораздо более простой интерфейс для хранилища данных, чем JDO или JPA, ион предназначен только для хранилища данных.

4 голосов
/ 21 ноября 2010

Я думаю, это дело вкуса. Решение ORM (JDO / JPA) обычно является более удобным. С другой стороны, низкоуровневый API обеспечивает полную гибкость, вы не ограничены никакими ограничениями ORM. Конечно, вам нужно написать больше кода, и вы можете написать свой собственный уровень абстракции хранилища данных. Но это может пригодиться, если вам понадобится оптимизировать некоторые вещи позже.

Но, конечно, вы можете начать использовать JDO / JPA, и если вы поймете, что вам нужно больше гибкости, вы все равно можете провести рефакторинг определенных частей вашего кода для использования низкоуровневых функций. Как уже упоминалось, внутренние ссылки сохраняются в виде идентификаторов (конечно же, для ключей).

В целом (в мире SQL) многие люди говорят, что, используя низкоуровневые материалы, вы больше узнаете о своей базе данных и, следовательно, получаете лучшее чувство для оптимизации. Есть много людей, которые используют ORM, но используют его очень неэффективно, потому что считают, что ORM выполняет всю работу за них. Поэтому они сталкиваются с проблемами производительности или обслуживания.

В конце концов, я думаю, что любое решение является правильным выбором, если вы не уверены. Но вам действительно следует ознакомиться с имеющимися документами и прочитать (блог) статьи, чтобы узнать о передовых методах, независимо от того, выбираете ли вы JDO / JPA или низкоуровневый.

Philip

...