JDO vs JPA dla Java w Google App Engine

Chcę rozwijać swój projekt w Google App Engine za pomocą Struts2. Do bazy danych mam dwie opcje JPA i JDO. Czy możecie mi to zasugerować? Obie są dla mnie nowe i muszę się ich nauczyć. Więc skupię się na jednym po twoich odpowiedziach.

Dzięki.

JPA jest standardem wytrwałości firmy Sun, JDO to umieranie IMHO (właściwie jest martwe, ale wciąż się porusza). Innymi słowy, WZP wydaje się lepszą inwestycją w perspektywie długoterminowej. Więc myślę, że wybrałbym JPA, gdyby oba były dla mnie nowe.

Grupa Google GAE / J ma kilka postów na ten temat. Szukałem tam i patrzyłem na opinie ludzi. Otrzymasz zupełnie inny przekaz niż opinie wyrażone powyżej. Skoncentruj się również na fakcie, że BigTable nie jest systemem RDBMS. Użyj odpowiedniego narzędzia do pracy

Właśnie zobaczyłem porównanie JPA i JDO przez samych DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Otwierający oczy.

Jestem szczęśliwym użytkownikiem JDO. Kontynuujcie dobrą robotę.

Ludzie twierdzący, że JDO nie żyje, nie są pozbawieni zasług. Oto, co przeczytałem w książce Pro EJB 3 Java Persistence API: „Wkrótce potem firma Sun ogłosiła, że ​​JDO zostanie zredukowane do trybu konserwacji specyfikacji i że Java Persistence API będzie czerpać zarówno z JDO, jak i innych dostawców trwałości i stanie się jedynym obsługiwanym standard w przyszłości. ”. Autor Mike Keith jest liderem specyfikacji w EJB3. Oczywiście jest wielkim zwolennikiem JPA, ale wątpię, czy jest na tyle stronniczy, by kłamać.

Prawdą jest, że kiedy książka została opublikowana, większość głównych dostawców była zjednoczona za JPA, a nie za JDO, mimo że JDO ma bardziej zaawansowane funkcje techniczne niż JPA. Nie jest to zaskakujące, ponieważ duzi gracze w świecie EE, tacy jak IBM / Oracle, są również dużymi dostawcami RDBMS. Więcej klientów używa w swoich projektach RDMBS niż innych niż RDMBS. JDO umierał, dopóki GAE nie przyspieszyło. Ma to sens, ponieważ magazyn danych GAE nie jest relacyjną bazą danych. Niektóre funkcje JPA nie działają z tabelami bigtable, takimi jak zapytania agregujące, zapytania typu Join, posiadane relacje „wiele do wielu”. BTW, GAE obsługuje JDO 2.3, podczas gdy obsługuje tylko JPA 1.0. Polecę JDO, jeśli GAE jest Twoją docelową platformą chmurową.

Dla przypomnienia jest to Google App Engine (GAE), więc gramy z regułami Google, a nie regułami Oracle / Sun.

Pod nim JPA nie nadaje się do GAE, jest niestabilny i nie działa zgodnie z oczekiwaniami. Ani Google nie chce go wspierać, ale absolutne minimum.

Z drugiej strony JDO jest dość stabilny w GAE i jest (w pewnym stopniu) dobrze udokumentowany przez Google.

Jednak Google nie poleca żadnego z nich.

http://code.google.com/appengine/docs/java/datastore/overview.html

Niskopoziomowy interfejs API zapewnia najlepszą wydajność, a GAE polega na wydajności.

http://gaejava.appspot.com/

Na przykład dodaj 10 jednostek

Python: 68 ms

JDO: 378 ms

Java Native: 30 ms

W wyścigu między JDO a JPA mogę tylko zgodzić się z plakatami datanucleus.

Przede wszystkim, i co najważniejsze, plakaty jądra danych wiedzą, co robią. W końcu rozwijają trwałą bibliotekę i znają inne niż relacyjne modele danych, np. Big Table. Jestem pewien, że gdyby był tutaj programista zajmujący się hibernacją, powiedziałby: „wszystkie nasze założenia podczas budowania naszych podstawowych bibliotek są ściśle powiązane z modelem relacyjnym, hibernacja nie jest zoptymalizowana pod kątem GAE”.

Po drugie, JPA jest niewątpliwie w bardziej powszechnym użyciu, będąc częścią oficjalnego stosu Java EE trochę pomaga, ale niekoniecznie oznacza to, że jest lepszy. W rzeczywistości JDO, jeśli o tym czytasz, odpowiada wyższemu poziomowi abstrakcji niż JPA. JPA jest ściśle powiązany z modelem danych RDBMS.

Z programistycznego punktu widzenia korzystanie z interfejsów API JDO jest znacznie lepszą opcją, ponieważ koncepcyjnie mniej kompromisów. Teoretycznie można przełączyć się na dowolny model danych według własnego uznania, pod warunkiem, że używany dostawca obsługuje bazową bazę danych. (W praktyce rzadko uzyskujesz tak wysoki poziom przejrzystości, ponieważ zdarzy się, że ustawiasz swoje klucze główne na obiekcie GAE i będziesz wiązał się z konkretnym dostawcą bazy danych, np. Google). migracja będzie jednak nadal łatwiejsza.

Po trzecie, możesz używać Hibernate, Eclipse Link, a nawet sprężyny z GAE. Wygląda na to, że Google poczynił duży wysiłek, aby umożliwić Ci korzystanie z frameworków, na których jesteś przyzwyczajony do tworzenia aplikacji. Ale ludzie zdają sobie sprawę, kiedy budują swoje aplikacje GAE tak, jakby działały na RDBMS, że są powolne. Wiosna na GAE jest powolna. Możesz wygooglować filmy Google IO na ten temat, aby zobaczyć, że to prawda.

Poza tym przestrzeganie standardów jest rozsądną rzeczą, którą w zasadzie oklaskuję. Z drugiej strony, JPA będąc częścią stosu Java EE sprawia, że ​​ludzie czasami tracą pojęcie o opcjach. Zrozum, jeśli chcesz, że Java Server Faces jest również częścią stosu Java EE. Jest to niewiarygodnie uporządkowane rozwiązanie do tworzenia internetowego interfejsu GUI. Ale ostatecznie, dlaczego ludzie, mądrzejsi ludzie, jeśli mogę tak powiedzieć, odchodzą od tego standardu i zamiast tego używają GWT?

W tym wszystkim muszę się przekonać, że JPA ma jedną bardzo ważną rzecz. To jest Guice i jego wygodna obsługa JPA. Wygląda na to, że Google nie był tak sprytny jak zwykle w tym momencie i jest zadowolony, na razie nie obsługując JDO. Nadal myślę, że ich na to stać i ostatecznie Guice pochłonie również JDO, ... a może nie.

Idź JDO. Nawet jeśli nie masz w tym doświadczenia, nie jest trudno go podnieść, a będziesz miał nową umiejętność pod pasem!

To, co uważam za okropne w używaniu tego JDOw momencie pisania, to fakt, że jedynym dostawcą wdrożeń jest, Datanucleusa jego wadą jest brak konkurencji, który prowadzi do wielu problemów, takich jak:

1. Niezbyt szczegółowa dokumentacja dotycząca niektórych aspektów, takich jak extensions
2. Zwykle otrzymujesz sarkastyczne odpowiedzi od autorów, takie jak (Czy sprawdzałeś logi? Może jest powód, dla którego je masz) i irytujące odpowiedzi takie jak te
3. Nie otrzymujesz odpowiedzi na swoje pytanie w pożytecznym czasie, czasami, jeśli otrzymasz odpowiedź w mniej niż 7 dni, powinieneś uważać się za szczęściarza, nawet tutaj StackOverflow

Zawsze mam nadzieję, że ktoś sam zacznie wdrażać JDOspecyfikację, może wtedy zaoferuje społeczności coś więcej i miejmy nadzieję, że będzie miał więcej darmowej uwagi i nie zawsze będzie zawracać sobie głowę zapłatą za wsparcie, nie mówiąc tegoDatanucleus autorom zależy tylko na wsparciu komercyjnym , ale ja tylko mówię.

Osobiście uważam, że Datanucleusautorzy nie mają żadnych zobowiązań wobec Datanucleussiebie ani swojej społeczności. W każdej chwili mogą zrezygnować z całego projektu i nikt nie może ich za to oceniać, to ich wysiłek i własna własność. Ale powinieneś wiedzieć, w co się pakujesz. Widzisz, gdy jeden z nas programistów szuka frameworka do użycia, nie możesz ukarać ani rozkazać autorowi frameworka, ale z drugiej strony musisz wykonać swoją pracę! Gdybyś miał czas na napisanie tego frameworka, dlaczego miałbyś go w ogóle szukać ?!

Z drugiej strony JDOsamo w sobie ma pewne komplikacje, takie jak cykl życia obiektów i rzeczy, które nie są zbyt intuicyjne i powszechne (tak mi się wydaje).

Edycja: Teraz wiem, że JPAwymusza również mechanizm cyklu życia obiektu, więc wygląda na to, że nieuniknione jest radzenie sobie ze stanami cyklu życia trwałych jednostek, jeśli chcesz użyć standardowego interfejsu API ORM (tj. JPALub JDO)

Najbardziej podoba mi JDOsię możliwość pracy z DOWOLNYM systemem zarządzania bazą danych bez większego wysiłku.

GAE / J ma dodać MYSQL przed końcem roku.

JPA jest drogą do zrobienia, ponieważ wydaje się być popychane jako standaryzowane API i ostatnio nabrało rozpędu w EJB3.0 .. Wydaje się, że JDO stracił parę.

Ani!

Użyj Objectify, ponieważ jest tańszy (zużywa mniej zasobów) i jest szybszy. FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify to interfejs API dostępu do danych w języku Java, zaprojektowany specjalnie dla magazynu danych Google App Engine. Zajmuje „środek”; łatwiejsze w użyciu i bardziej przejrzyste niż JDO lub JPA, ale znacznie wygodniejsze niż Low-Level API. Objectify ma na celu natychmiastowe zwiększenie produktywności nowicjuszy, a jednocześnie ujawnienie pełnej mocy magazynu danych GAE.

Objectify pozwala utrwalać, pobierać, usuwać i wysyłać zapytania do własnych wpisanych obiektów.

@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);