Я хочу розробити свій проект на Google App Engine за допомогою Struts2. Для бази даних у мене є два варіанти JPA та JDO. Будь ласка, запропонуйте мені, будь ласка, це? І те, і інше для мене нове, і мені потрібно їх вивчити. Тож я зосереджусь на одному після ваших відповідей.
Дякую.
Відповіді:
JPA - це стандарт Сонця для стійкості, JDO - це ІМХО, яка вмирає (насправді, вона мертва, але все ще рухається). Іншими словами, JPA здається кращою інвестицією в довгостроковій перспективі. Тож, мабуть, я б обрав JPA, якби обидва для мене були новими.
Гугл-група 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. Це не дивно, оскільки такі великі гравці у світі ЕЕ, як IBM / Oracle, також є великими постачальниками СУБД. Більше клієнтів використовують RDMBS, ніж не RDMBS у своїх проектах. JDO вмирав, поки GAE не дав йому значного поштовху. Це має сенс, оскільки сховище даних GAE не є реляційною базою даних. Деякі функції JPA не працюють з великими таблицями, такими як запити агрегування, запити на приєднання, відносини багато-до-багатьох. До речі, 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 знають, що вони роблять. Зрештою, вони розробляють стійку бібліотеку і знайомі з іншими моделями даних, крім реляційних, наприклад, "Велика таблиця". Я впевнений, що тут був розробник hibernate, він сказав би: "всі наші припущення при побудові наших основних бібліотек тісно пов'язані з реляційною моделлю, сплячий режим не оптимізований для GAE".
По-друге, JPA, безперечно, широко використовується, оскільки частина офіційного стеку Java EE трохи допомагає, але це не обов'язково означає, що він кращий. Насправді, якщо ви про це читаєте, JDO відповідає вищому рівню абстракції, ніж JPA. JPA тісно пов'язана з моделлю даних RDBMS.
З точки зору програмування, використання JDO API є набагато кращим варіантом, оскільки ви концептуально компрометуєте набагато менше. Ви можете теоретично перейти на будь-яку модель даних за вашим бажанням, за умови, що постачальник, який ви використовуєте, підтримує базову базу даних. (На практиці ви рідко досягаєте такого високого рівня прозорості, оскільки ви виявите, що встановлюєте свої первинні ключі на об'єкті GAE, і будете прив'язуватись до певного постачальника баз даних, наприклад, google). все одно буде легше мігрувати.
По-третє, ви можете використовувати Hibernate, Eclipse Link і навіть пружину з 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застосовується механізм життєвого циклу об'єкта, тому, схоже, неминуче мати справу зі збереженими станами життєвого циклу, якщо ви хочете використовувати стандартний 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);