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.
java
google-app-engine
jpa
jdo
Tahir Akram
źródło
źródło
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
źródło
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.
źródło
Jestem szczęśliwym użytkownikiem JDO. Kontynuujcie dobrą robotę.
źródło
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ą.
źródło
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
źródło
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.
źródło
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!
źródło
To, co uważam za okropne w używaniu tego
JDO
w momencie pisania, to fakt, że jedynym dostawcą wdrożeń jest,Datanucleus
a jego wadą jest brak konkurencji, który prowadzi do wielu problemów, takich jak:extensions
StackOverflow
Zawsze mam nadzieję, że ktoś sam zacznie wdrażać
JDO
specyfikację, 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
Datanucleus
autorzy nie mają żadnych zobowiązań wobecDatanucleus
siebie 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
JDO
samo 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
JPA
wymusza 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.JPA
LubJDO
)Najbardziej podoba mi
JDO
się możliwość pracy z DOWOLNYM systemem zarządzania bazą danych bez większego wysiłku.źródło
GAE / J ma dodać MYSQL przed końcem roku.
źródło
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ę.
źródło
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 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);
źródło