Hibernacja vs JPA vs JDO - wady i zalety każdego z nich? [Zamknięte]

174

Jestem zaznajomiony z pojęciem ORM, a kilka lat temu używałem nHibernate do projektu .NET; jednak nie nadążałem za tematem ORM w Javie i nie miałem okazji użyć żadnego z tych narzędzi.

Ale teraz być może będę miał szansę zacząć używać niektórych narzędzi ORM w jednej z naszych aplikacji, próbując odejść od szeregu starszych usług internetowych.

Trudno mi powiedzieć, jaka jest różnica między specyfikacją JPA, tym, co otrzymujesz z samą biblioteką Hibernate i co ma do zaoferowania JDO.

Rozumiem więc, że to pytanie jest nieco otwarte, ale liczyłem na kilka opinii na temat:

  • Jakie są zalety i wady każdego z nich?
  • Co byś zaproponował do nowego projektu?
  • Czy istnieją pewne warunki, w których warto byłoby zastosować jedną strukturę w porównaniu z drugą?
java hibernate orm jpa jdo matowe b
źródło

Odpowiedzi:

112

Kilka uwag:

  • JDO i JPA to specyfikacje, a nie implementacje.
  • Pomysł jest taki, że możesz zamienić implementacje JPA, jeśli ograniczysz kod do używania tylko standardowego JPA. (To samo dotyczy JDO.)
  • Hibernacja może służyć jako jedna z takich implementacji JPA.
  • Jednak Hibernate zapewnia natywny interfejs API z funkcjami wykraczającymi poza JPA.

IMO, polecam Hibernate.

Pojawiło się kilka komentarzy / pytań dotyczących tego, co należy zrobić, jeśli konieczne jest użycie funkcji specyficznych dla Hibernacji. Można na to spojrzeć na wiele sposobów, ale moja rada brzmi:

  • Jeśli nie martwi Cię perspektywa powiązania z dostawcą, dokonaj wyboru między Hibernate a innymi wdrożeniami JPA i JDO, w tym różnymi rozszerzeniami specyficznymi dla dostawcy w podejmowaniu decyzji.

  • Jeśli martwi Cię perspektywa powiązania z dostawcą i nie możesz używać JPA bez uciekania się do rozszerzeń specyficznych dla dostawcy, nie używaj JPA. (To samo dotyczy JDO).

W rzeczywistości prawdopodobnie będziesz musiał znaleźć kompromis między tym, jak bardzo martwi Cię powiązanie z dostawcą, a ile potrzebujesz tych rozszerzeń specyficznych dla dostawcy.

Są też inne czynniki, takie jak to, jak dobrze Ty / Twoi pracownicy znacie odpowiednie technologie, ile będą kosztować produkty w ramach licencji i czyją historię o tym, co stanie się w przyszłości dla JDO i JPA.

zestaw narzędzi
źródło
8
zestaw narzędzi, ładny i krótki. Kolejną kwestią, o której warto wspomnieć, jest to, że JPA nie uniemożliwia korzystania z funkcji specyficznych dla implementacji, jeśli to konieczne. Oznacza to, że JPA umożliwia korzystanie z dowolnej funkcji hibernacji, gdy Hibernacja jest implementacją.
topchef
1
Jakie byłyby zalety korzystania z JPA, jeśli potrzebuję jakiejś konkretnej funkcji z Hibernate?
Bruno Reis
22
Ważna uwaga, którą należy dodać: chociaż JPA i JDO oba mają doskonałe wsparcie dla RDBMS, JDO jest agnostykiem „datastore”, a więc nie ogranicza się do świata RDBMS. Biorąc pod uwagę wzrost popularności NoSQL w tej chwili, rozsądnie byłoby rozważyć użycie standardu trwałości, który pozwala uniknąć blokowania aplikacji w tradycyjnym świecie * SQL. Aplikacje JDO można łatwo wdrażać w magazynach danych innych niż RDBMS. Pełną listę obsługiwanych magazynów danych można znaleźć pod adresem: datanucleus.org/products/accessplatform/datastores.html
Volksman
2
@Golfman po co wybierać na podstawie tego, co może się wydarzyć? Nic nie stoi na przeszkodzie, abyś później wrzucił coś innego, jeśli kiedykolwiek będziesz potrzebować obsługi NoSQL ... KISS
TM.
1
@Bruno - gdy używasz non-Hibernate specyficzne części Hibernate, to są za pomocą JPA. Oczywiście zaletą ograniczenia się do czystego JPA jest to, że można łatwiej przełączyć się na inną implementację JPA.
Stephen C,
69

Upewnij się, że oceniłeś implementację JDO DataNucleus. Zaczęliśmy od Hibernate, ponieważ wydawał się być tak popularny, ale dość szybko zdaliśmy sobie sprawę, że nie jest to w 100% przezroczyste rozwiązanie do trwałości. Jest zbyt wiele zastrzeżeń, a dokumentacja jest pełna „jeśli masz taką sytuację, musisz napisać swój kod w ten sposób”, co odebrało radość swobodnego modelowania i kodowania w dowolny sposób. JDO nigdy nie spowodowało, że dostosowałem mój kod lub model, aby „działał poprawnie”. Mogę po prostu zaprojektować i zakodować proste POJO, tak jakbym miał używać ich tylko „w pamięci”, ale mogę je utrwalać w sposób przejrzysty.

Inną zaletą JDO / DataNucleus w porównaniu z hibernacją jest to, że nie ma całego narzutu odbicia w czasie wykonywania i jest bardziej wydajna w pamięci, ponieważ wykorzystuje ulepszenie kodu bajtowego czasu kompilacji (może dodać 1 sekundę do czasu kompilacji dla dużego projektu). niż wzorzec proxy zasilany w czasie wykonywania przez hibernację.

Inną rzeczą, która może Cię denerwować w przypadku Hibernate, jest to, że odniesienie do tego, co myślisz, jest obiektem ... często jest to „proxy” dla obiektu. Bez korzyści w postaci ulepszenia kodu bajtowego wzorzec proxy jest wymagany, aby umożliwić ładowanie na żądanie (tj. Uniknąć ściągania całego grafu obiektowego podczas ściągania obiektu najwyższego poziomu). Przygotuj się na zastąpienie równości i hashcode, ponieważ obiekt, do którego myślisz, że się odwołujesz, jest często tylko serwerem proxy dla tego obiektu.

Oto przykład frustracji, które dostaniesz dzięki Hibernate, a których nie uzyskasz dzięki JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Jeśli lubisz kodować w celu obejścia problemu, z pewnością Hibernate jest dla Ciebie. Jeśli cenisz czysty, czysty, zorientowany obiektowo, oparty na modelach programowanie, w którym cały swój czas spędzasz na modelowaniu, projektowaniu i kodowaniu, bez brzydkich obejść, poświęć kilka godzin na ocenę JDO / DataNucleus . Zainwestowane godziny zostaną zwrócone tysiąckrotnie.

Aktualizacja z lutego 2017 r

Od dłuższego czasu DataNucleus wdraża standard trwałości JPA oprócz standardu trwałości JDO, więc przenoszenie istniejących projektów JPA z Hibernate do DataNucleus powinno być bardzo proste, a wszystkie wyżej wymienione zalety DataNucleus można uzyskać przy niewielkiej zmianie kodu , Jeśli w ogóle. Więc jeśli chodzi o wybór konkretnego standardu, JPA (tylko RDBMS) vs JDO (RDBMS + No SQL + ODBMSes + inne), DataNucleus obsługuje oba, Hibernate jest ograniczone tylko do JPA.

Wydajność aktualizacji Hibernate DB

Kolejną kwestią, którą należy wziąć pod uwagę przy wyborze ORM, jest skuteczność jego brudnego mechanizmu sprawdzania - staje się to bardzo ważne, gdy trzeba skonstruować SQL, aby zaktualizować obiekty, które zmieniły się w bieżącej transakcji - zwłaszcza gdy jest dużo obiektów. W tej odpowiedzi SO jest szczegółowy opis techniczny brudnego mechanizmu sprawdzania Hibernate'a: JPA z wstawką HIBERNATE bardzo wolno

Volksman
źródło
3
Jak wszyscy wiemy, właśnie ulepszanie jest powodem, dla którego JDO zostało tak szeroko przyjęte!
Pascal Thivent
15
Dobrze nagłośnione FUD i astroturfing wykonane przez kluczowych graczy Hibernate we wczesnych latach w odniesieniu do JDO jest niczym innym jak nieuczciwym i obrzydliwym i bez wątpienia miało jakiś wpływ na przyjęcie JDO. W dzisiejszych czasach programiści wiedzą, że ulepszanie kodu bajtowego wcale nie stanowi problemu i często używają go do wielu różnych celów, innych niż utrwalanie. Nowa biblioteka ulepszeń kodu bajtowego ASM jest tak błyskawiczna, że ​​nie masz nawet czasu na odetchnięcie, zanim to zrobisz.
Volksman
7
Awaria JDO była przewidywana od samego początku ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) i przed Hibernate, więc nie można winić za to Hibernate. Hibernate / Toplink odniósł sukces tam, gdzie gracze Sun i JDO (i ich OODBMS) zawiedli, ponieważ mieli wtedy lepsze odpowiedzi, a nie z powodu marketingu i FUD. Kropka. Kogo obchodzi, czy ASM płonie dzisiaj szybko , nie było go 5+ lat temu, kiedy było potrzebne, a JDO po prostu przegrał bitwę. JDO jest koncepcyjnie lepsze? Szkoda, nie udało mu się terminowo zrealizować zwycięzcy (i nie wróci z powodu JPA).
Pascal Thivent
2
Aby zilustrować moje słowa (kolejny post, który ilustruje ból, jaki ludzie odczuwali podczas opracowywania lub dlaczego Hibernate wygrał bitwę): mail-archive.com/[email protected]/… . Wydaje mi się oczywiste, że refleksja / cglib była praktyczną odpowiedzią na problemy ludzi (a ludzi nie obchodzi, czy API jest koncepcyjnie lepsze, jeśli jest to trudne w użyciu) i nie widzę tutaj żadnych kluczowych graczy Hibernacji, tylko użytkownicy . Więc na koniec zastanawiam się, kto właściwie rozprowadza FUD ...
Pascal Thivent
7
Cóż, z pewnością nie jest to tak, jak za dawnych czasów, kiedy byłoby co najmniej 17 różnych postów pro Hibernate FUD (ale pochodzących tylko z 3 różnych adresów IP. Do matematyki people =)).
Volksman
54

Niedawno oceniłem i wybrałem ramy trwałości dla projektu Java, a moje ustalenia są następujące:

Widzę, że wsparcie na rzecz JDO to przede wszystkim:

  • możesz używać źródeł danych innych niż sql, db4o, hbase, ldap, bigtable, couchdb (wtyczki do cassandra) itp.
  • możesz łatwo przełączyć się ze źródła danych sql na inne niż sql i odwrotnie.
  • brak obiektów proxy, a tym samym mniej problemów z implementacjami hashcode () i equals ()
  • więcej POJO, a tym samym mniej wymaganych obejść
  • obsługuje więcej typów relacji i pól

a poparcie na rzecz WZP to przede wszystkim:

  • bardziej popularny
  • jdo nie żyje
  • nie używa rozszerzenia kodu bajtowego

Widzę wiele postów pro-JPA od programistów JPA, którzy wyraźnie nie używali JDO / Datanucleus, oferujących słabe argumenty za nieużywaniem JDO.

Widzę również wiele postów od użytkowników JDO, którzy przenieśli się do JDO i dzięki temu są o wiele szczęśliwsi.

Biorąc pod uwagę większą popularność JPA, wydaje się, że jest to częściowo spowodowane wsparciem dostawców RDBMS, a nie lepszym technicznie. (Dla mnie brzmi jak VHS / Betamax).

JDO i jego referencyjna implementacja Datanucleus najwyraźniej nie jest martwy, jak pokazuje przyjęcie go przez Google do GAE i aktywne tworzenie kodu źródłowego (http://sourceforge.net/projects/datanucleus/).

Widziałem wiele skarg dotyczących JDO z powodu ulepszenia kodu bajtowego, ale nie ma jeszcze wyjaśnienia, dlaczego jest źle.

W rzeczywistości w świecie, który ma coraz większą obsesję na punkcie rozwiązań NoSQL, JDO (i implementacja datanucleus) wydaje się znacznie bezpieczniejszym rozwiązaniem.

Właśnie zacząłem używać JDO / Datanucleus i skonfigurowałem go tak, aby móc łatwo przełączać się między użyciem db4o i mysql. Przy szybkim programowaniu pomocne jest użycie db4o i nie trzeba martwić się zbytnio o schemat bazy danych, a następnie, gdy schemat zostanie ustabilizowany, w celu wdrożenia w bazie danych. Jestem również pewien, że później będę mógł wdrożyć całą / część mojej aplikacji w GAE lub skorzystać z rozproszonej pamięci masowej / map-zredukuj a la hbase / hadoop / cassandra bez zbytniego refaktoryzacji.

Początkowa przeszkoda związana z rozpoczęciem pracy z Datanucleus była trochę skomplikowana - Dokumentacja na stronie internetowej Datanucleus jest trochę trudna do zrozumienia - samouczki nie są tak łatwe do wykonania, jak bym chciał. Powiedziawszy to, bardziej szczegółowa dokumentacja dotycząca API i mapowania jest bardzo dobra, gdy przejdziesz przez początkową krzywą uczenia się.

Odpowiedź brzmi: to zależy od tego, czego chcesz. Wolałbym mieć bardziej przejrzysty kod, brak dostępu do dostawcy, bardziej zorientowane na pojo, opcje nosql a bardziej popularne.

Jeśli chcesz mieć ciepłe, wybredne wrażenie, że robisz to samo, co większość innych programistów / owiec, wybierz JPA / hibernacja. Jeśli chcesz być liderem w swojej dziedzinie, wypróbuj JDO / Datanucleus i podejmij decyzję.

Tomek
źródło
9
Właściwie, tak jak powiedziałem, po prostu dawałem wrażenia z tego, co odkryłem, próbując wybrać rozwiązanie. Tak, jestem początkującym w Javie, dlaczego miałoby to być tak powściągliwe? Ty, z drugiej strony, publikowałeś wiele razy swoją opinię, że JDO nie żyje, nie przedstawiając żadnych faktów ani dowodów na poparcie tego, ani nie uwzględniając obszarów technicznych, w których JDO jest wyraźnie lepsze. Oczywiście masz coś osobistego przeciwko JDO / Datanucleus i używasz tych wątków jako środka do utrwalenia swojego stanowiska przeciwko JDO.
Tom
4
Pascal - walczysz tutaj o kąt. Myślę, że brakuje Ci sensu sekcji Reklama w FAQ. PO poprosił o opinie na temat 2 technologii. Zachęca osoby wspierające którąkolwiek ze stron do wystąpienia i przedstawienia konstruktywnej krytyki / zaleceń. Dla Andy / Datanucleus i innych użytkowników JDO podkreślanie pozytywów JDO i obrona przed krytyką nie jest niczym więcej jak reklamą, niż ktoś inny tutaj zalecający użycie hibernacji.
Tom
5
Dobrze by było, gdybyś odniósł się do sekcji FAQ, która mówi „Bądź miły”, bo twoje posty na ten temat były oskarżycielskie, konfrontacyjne lub po prostu niegrzeczne. Twoim pierwszym był sarkastyczny komentarz dotyczący ulepszenia. Druga; rant na temat trudności wczesnych wdrożeń i nie ma już znaczenia. Trzecia była dziecinna kpina i zniewaga dla tych, którzy woleliby nie używać RDBMS. Po czwarte, było sarkastyczne kpienie z kogoś, kto ma inne poglądy na ciebie. Piąty to atak; nazywa mnie papugą. Czy uważasz to za „bycie miłym”?
Tom
3
Jeśli miałeś okropne doświadczenie z JDO, wyjaśnij, co było okropne, przyznaj, że było to we wcześniejszej wersji i od tego czasu mogło się poprawić. Musisz także zdawać sobie sprawę z tego, że inni mogą mieć inne potrzeby. To, że jesteś „zadowolony” z JPA i chcesz używać RDBMS, nie oznacza, że ​​inni są. Może w pośpiechu, aby podnieść swoją reputację, straciłeś z oczu, jaką reputację można nagrodzić? ps. Jako programista powinieneś być naprawdę zainteresowany dobrym samopoczuciem takich projektów, ponieważ to napędza innowacje i zmniejsza uzależnienie od dostawcy.
Tom
6
To będzie moja ostateczna odpowiedź :) .. 1. Jeśli nie należało zadawać sobie pytania, po co to podnosić? 2. Nigdy nie kwestionowałem Twojej uczciwości, powiedziałem, że nie byłeś miły dla innych plakatów i zaprzeczałeś sobie. 3. nikt nie sugerował podsumowania 8+ lat - ale popieraj swoje stwierdzenia faktami i przykładami, a nie subiektywnymi stwierdzeniami, które mogą urazić. 5. Gdzie w tym poście jest postawa „hibernacja / jpa / jboss jest zła”? Nie widzę tego. Widzę tylko twoje komentarze anty-JDO.
Tom
40

Co byś zaproponował do nowego projektu?

Nie sugerowałbym też! Zastosowanie Wiosna DAO jest JdbcTemplaterazem z StoredProcedure, RowMappera RowCallbackHandlerzamiast tego.

Moje osobiste doświadczenie z Hibernate jest takie, że czas zaoszczędzony z góry jest więcej niż rekompensowany przez niekończące się dni, które spędzisz w trakcie próbowania zrozumienia i debugowania problemów, takich jak nieoczekiwane kaskadowe zachowanie aktualizacji.

Jeśli korzystasz z relacyjnej bazy danych, to im bliżej jej jest Twój kod, tym większą masz kontrolę. Warstwa DAO Springa umożliwia precyzyjną kontrolę warstwy mapowania, jednocześnie eliminując potrzebę stosowania standardowego kodu. Ponadto integruje się z warstwą transakcyjną Springa, co oznacza, że ​​możesz bardzo łatwo dodawać (przez AOP) skomplikowane zachowania transakcyjne bez ingerencji w kod (oczywiście, otrzymujesz to również z Hibernate).

oxbow_lakes
źródło
4
jest to wyraźnie wybór mapowania relacyjno-obiektowego (ORM), napędzany przez dużą bazę użytkowników i kodu zgromadzoną od czasów ODBC (wczesne lata 90-te) (czytaj dziedzictwo). Nie ma powodu, aby nie używać JDBC (ze Springiem lub bez), chyba że zdecydujesz się przejść dalej i użyć frameworka ORM. Pomyśl o ludziach, którzy pewnego dnia zdecydowali się porzucić FORTRAN, aby używać C lub Pascala.
topchef
23
@grigory - mówię z dużym doświadczeniem marnowania dni na próbach zrozumienia problemów Hibernacji, takich jak kaskadowe aktualizacje / usunięcia, absurdalnie nieefektywne struktury zapytań itp. Rozwiązania ORM są „szybkim sposobem na wygraną” dla tych, którzy nie rozumieją relacyjnych baz danych. W związku z tym jest mało prawdopodobne, aby znajomość samego Hibernate'a zaowocowała dobrym produktem końcowym. Z mojego doświadczenia wynika, że ​​w całym cyklu życia projektu Hibernate (i ORM przez rozszerzenie) kosztuje więcej czasu niż oszczędza
oxbow_lakes,
8
przepraszam, że miałeś tak słabe doświadczenia z Hibernate. Sam pochodzę z ciężkiej bazy danych / SQL / procedury składowanej / szkoły JDBC. Nie mogę powiedzieć, że jestem konwertowany - każda powyższa technologia wciąż ma swoje miejsce. Ale do ogólnego zastosowania trójwarstwowej aplikacji Java (bez względu na rozmiar) pierwszym wyborem jest technologia ORM - najlepiej JPA 2. Inne należy rozważyć w oparciu o takie czynniki: starszy kod, integracja, doświadczenie, duże wymagania wsadowe, czas rzeczywisty wydajność itp., które mogą kierować (lub nie) podejściem do różnych technologii baz danych.
topchef
3
Zupełnie nie zgadzam się z powyższą definicją „szybkiego wygrania” - po prostu chwyć Hibernate in Action ( stackoverflow.com/questions/96729/ ... ) (i to JPA 1, z JPA 2 robi się tylko lepiej), aby w pełni zrozumieć moc i zasięg tej technologii ma.
topchef
7
Zrobiłem trochę badań i Spring nie poleca już Spring DAO ( static.springsource.org/spring/docs/3.0.x/ ... ): „Zalecanym stylem integracji jest kodowanie DAO z prostymi interfejsami API Hibernate, JPA i JDO. starszy styl używania szablonów DAO Springa nie jest już zalecany; „... Czy to właśnie zalecałeś? Jeśli tak, dlaczego tego nie polecają?
Użytkownik 1,
23

JDO nie żyje

JDO właściwie nie umarło, więc proszę sprawdzić fakty. JDO 2.2 zostało wydane w październiku 2008 JDO 2.3 jest w fazie rozwoju.

Jest to otwarcie rozwijane pod Apache. Więcej wydań niż miał JPA, a jego specyfikacja ORM wciąż wyprzedza proponowane funkcje JPA2

DataNucleus
źródło
12
Ludzie z pewnością go używają, o czym świadczy wielu użytkowników, których DataNucleus ma, nie wspominając o Xcalia, Kodo. Tęsknisz za podstawowym pomysłem, że JDO i JPA nie zajmują tego samego rynku. JPA to wyłącznie RDBMS. JDO jest niezależny od datastore i jest używany dla RDBMS, ale także LDAP, XML, Excel, OODBM itp.
DataNucleus
3
Podoba mi się czynnik inny niż RDBMS, szczególnie biorąc pod uwagę wzrost popularności rozwiązań innych niż RDBMS, to wielka sprawa. Oznacza to, że jeśli JPA nie ewoluuje wystarczająco szybko, dostępność „bardziej otwartej” i elastycznej alternatywy (JDO) oznacza, że ​​popularność JPA będzie z konieczności spadać. Nieważne techniczne argumenty, że JDO jest bardziej kompletne, lepsze, dojrzałe czy cokolwiek innego - nie będzie to kwestia preferencji . To ma sens, że dostawcy RDBMS zachowują się podejrzanie - dni dominacji na rynku RDBMS mogą dobiegać końca.
Manius,
Nadal używamy JDO / DataNucleus w 2019 roku! Jest teraz dostępna do wersji 5.xi nadal przewyższa Hibernację pod względem produktywności programistów i wydajności w czasie wykonywania. Niedawno musiałem konsultować się z dużą aplikacją internetową przy użyciu Hibernate i przypomniałem sobie o bólu, jaki odczułem, kiedy byłem aktywnym użytkownikiem i promotorem HIbernate wiele lat temu. Kierownik zespołu nie uwierzył mi, gdy powiedziałem jej, że jej pole BLOB był zawsze chętnie pobierany, mimo że był oznaczony jako lazy fetched. Całkowity brak wiedzy „pod maską” przez „doświadczonego” samozwańczego eksperta Hibernate był niestety niepokojący, ale oczekiwany.
Volksman
10

Używam JPA (implementacja OpenJPA z Apache, która jest oparta na bazie kodu KODO JDO, która ma ponad 5 lat i jest wyjątkowo szybka / niezawodna). IMHO każdy, kto każe ci ominąć specyfikacje, daje ci złą radę. Poświęciłem czas i zdecydowanie zostałem nagrodzony. Za pomocą JDO lub JPA możesz zmieniać dostawców przy minimalnych zmianach (JPA ma mapowanie ORM, więc mówimy mniej niż jeden dzień, aby ewentualnie zmienić dostawców). Jeśli masz ponad 100 stołów, tak jak ja, to jest ogromne. Dodatkowo otrzymujesz wbudowane buforowanie z eksmisjami z pamięci podręcznej klastra i wszystko jest w porządku. SQL / Jdbc nadaje się do zapytań o wysokiej wydajności, ale przezroczysta trwałość jest znacznie lepsza w przypadku pisania algorytmów i procedur wprowadzania danych. Mam tylko około 16 zapytań SQL w całym systemie (ponad 50 tysięcy wierszy kodu).


źródło
8

Sam się tym przyglądałem i nie mogę znaleźć między nimi dużej różnicy. Myślę, że duży wybór polega na tym, w której implementacji używasz. Sam rozważałem platformę DataNucleus , ponieważ jest to niezależna od magazynu danych implementacja obu.

tapi
źródło
6
+1 dla DataNucleus, a nie dla odpowiedzi.
WolfmanDragon
8

Każdy, kto mówi, że JDO nie żyje, jest astroturfingowym handlarzem FUD i oni o tym wiedzą.

JDO żyje i ma się dobrze. Specyfikacja jest wciąż mocniejsza, dojrzała i bardziej zaawansowana niż znacznie młodszy i ograniczony JPA.

Jeśli chcesz ograniczyć się tylko do tego, co jest dostępne w standardzie JPA, możesz pisać do JPA i używać DataNucleus jako wydajnej, bardziej przejrzystej implementacji trwałości niż inne implementacje JPA. Oczywiście DataNucleus implementuje również standard JDO, jeśli chcesz elastyczności i wydajności modelowania, które zapewnia JDO.

Volksman
źródło
1
Lub używasz innej (dobrze) implementacji ze znacznie większą, a co za tym idzie, bardziej responsywną społecznością. Tak, niektórych ludzi też to obchodzi.
Pascal Thivent
1
A ty mówisz o FUD> :) Zabawne.
Pascal Thivent
2
Twój komentarz wydaje się zakładać, że nie korzystałem z Hibernate i JDO.
Volksman
2
Wydaje się, że ten wątek ma bardzo dużo odniesień od kilku osób do tego, jak świetny jest DataNucleus. Nie używaj tego miejsca jako platformy reklamowej.
TM.
3
Nic dziwnego ze strony Golfmana, który w kółko wkleja te same desperackie materiały marketingowe w każdym wątku dotyczącym JPA lub DataNucleus (którego używa od 1996 roku , zanim jeszcze istniały !).
Pascal Thivent
2

Użyłem Hibernate (implementacja JPA) i JPOX (implementacja JDO) w tym samym projekcie. JPOX działał dobrze, ale dość szybko napotkał błędy, gdzie niektóre funkcje języka Java 5 nie były obsługiwane w tym czasie. Miał problemy z dobrą zabawą z transakcjami XA. Generowałem schemat bazy danych z obiektów JDO. Chciała łączyć się z bazą danych za każdym razem, co jest denerwujące, jeśli połączenie z Oracle nie działa.

Następnie przeszliśmy na Hibernację. Przez chwilę bawiliśmy się po prostu używając czystego JPA, ale musieliśmy użyć niektórych funkcji specyficznych dla Hibernacji, aby wykonać mapowanie. Uruchamianie tego samego kodu w wielu bazach danych jest bardzo łatwe. Hibernacja wydaje się agresywnie buforować obiekty lub czasami zachowuje się dziwnie. Istnieje kilka konstrukcji DDL, których Hibernate nie obsługuje, dlatego są one zdefiniowane w dodatkowym pliku, który jest uruchamiany w celu zainicjowania bazy danych. Kiedy napotykam problem z Hibernacją, często wiele osób napotyka ten sam problem, co ułatwia wyszukiwanie rozwiązań w Google. Wreszcie, Hibernate wydaje się być dobrze zaprojektowane i niezawodne.

Niektórzy inni respondenci sugerowali użycie języka SQL. Prawdziwym zabójczym przypadkiem użycia mapowania relacyjno-obiektowego jest testowanie i rozwój. Bazy danych zbudowane do obsługi dużych ilości danych są zazwyczaj drogie i / lub trudne do zainstalowania. Trudno z nimi przetestować. Istnieje wiele baz danych Java w pamięci, których można używać do testowania, ale zazwyczaj są one bezużyteczne w środowisku produkcyjnym. Możliwość korzystania z prawdziwej, ale ograniczonej bazy danych zwiększy produktywność programowania i niezawodność kodu.

Sean McCauliff
źródło
1
O ile wiem, JPOX zmienił nazwę na DataNucleus (i od tego czasu ma wydania).
Donal Fellows
2
Myślisz, że faktycznie zauważysz, że DataNucleus ma znacznie mniej otwartych błędów niż inne oprogramowanie, do którego się odnosisz. Pomyśl też, że rozwój DataNucleus zmniejsza liczbę błędów w szybszym tempie niż inne oprogramowanie.
DataNucleus
1

Zrobiłem przykładową aplikację internetową w maju 2012, która korzysta z JDO 3.0 i DataNucleus 3.0 - zobacz, jaka jest czysta: https://github.com/TorbenVesterager/BadAssWebApp

No dobra, może to trochę za czyste, ponieważ używam POJO zarówno dla bazy danych, jak i klienta JSON, ale jest fajnie :)

PS: zawiera kilka adnotacji SuppressWarnings (opracowanych w IntelliJ 11)

Torben Vesterager
źródło