Hibernate vs JPA vs JDO-plusy i minusy każdego? [zamknięte]

Upewnij się, że oceniasz implementację DataNucleus JDO. Zaczęliśmy od Hibernate, ponieważ wydawało się, że jest tak popularny, ale wkrótce zdaliśmy sobie sprawę, że nie jest to w 100% przezroczyste rozwiązanie trwałości. Istnieje zbyt wiele zastrzeżeń, a dokumentacja jest pełna "jeśli masz taką sytuację, to musisz napisać swój kod w ten sposób", które zabrały frajdę z swobodnego modelowania i kodowania, jak tylko chcemy. JDO nie Nigdy spowodowało, że dostosowałem mój kod lub mój model, aby go uruchomić właściwie". Mogę po prostu zaprojektować i zakodować proste Pojo, tak jakbym miał je używać tylko "w pamięci" , ale mogę je zachować przejrzyście.

Inną zaletą JDO/DataNucleus nad hibernate jest to, że nie ma całego narzutu odbicia czasu wykonania i jest bardziej wydajna pamięć, ponieważ używa rozszerzenia kodu bajtowego czasu kompilacji (może dodać 1 SEK do czasu kompilacji dla dużego projektu) zamiast wzorca proxy opartego na odbiciu czasu wykonania hibernate.

Another thing you irytujące może być to, że Hibernate odnosi się do tego, co Twoim zdaniem jest obiektem... często jest to "proxy" dla obiektu. Bez korzyści z rozszerzenia kodu bajtowego wzorzec proxy jest wymagany, aby umożliwić ładowanie na żądanie (tj. unikanie ciągnięcia całego wykresu obiektów, gdy przeciągasz obiekt najwyższego poziomu). Przygotuj się na nadpisanie równości i hashcode, ponieważ obiekt, do którego się odnosisz, jest często tylko proxy dla tego obiektu.

Oto przykład frustracje, które dostaniesz z Hibernate, których nie dostaniesz z JDO:

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

Jeśli lubisz kodowanie na "obejścia", to Hibernate jest dla ciebie. Jeśli cenisz czysty, czysty, zorientowany obiektowo rozwój oparty na modelach, w którym cały czas poświęcasz na modelowanie, projektowanie i kodowanie, A nie na brzydkie obejścia, poświęć kilka godzin ocena JDO / DataNucleus . Zainwestowane godziny zostaną zwrócone tysiąckrotnie.

Aktualizacja Luty 2017

Od dłuższego czasu DataNucleus implementuje standard JPA persistence oprócz standardu JDO persistence, więc przenoszenie istniejących projektów JPA z Hibernate do DataNucleus powinno być bardzo proste i można uzyskać wszystkie wyżej wymienione korzyści z DataNucleus przy bardzo małej zmianie kodu, jeśli w ogóle. Tak więc w kwestii pytania, wybór szczególny standard, JPA (tylko RDBMS) vs JDO (RDBMS + No SQL + ODBMSes + inne), DataNucleus obsługuje oba, Hibernate jest ograniczony tylko do JPA.

Wydajność aktualizacji Hibernate DB

Kolejną kwestią do rozważenia przy wyborze ORM jest wydajność jego mechanizmu sprawdzania brudu - co staje się bardzo ważne, gdy musi skonstruować SQL, aby zaktualizować obiekty, które zmieniły się w bieżącej transakcji - zwłaszcza gdy istnieje wiele obiektów. Jest szczegółowy opis techniczny mechanizmu sprawdzania brudu Hibernate ' a w tym więc odpowiedz: JPA z wstawką HIBERNATE bardzo wolno

Niedawno oceniłem i wybrałem Framework persistence dla projektu java i moje wnioski są następujące:

Widzę, że poparcie dla JDO to przede wszystkim:

• możesz używać nie-sql datasources, db4o, hbase, LDAP, bigtable, CouchDB (wtyczki dla Cassandry) itp.
• możesz łatwo przełączyć się ze źródła danych sql na inne niż sql i odwrotnie.
• brak obiektów proxy i tym samym mniej bólu w odniesieniu do hashcode () i równa się() implementacje
• więcej POJO, a tym samym mniej obejścia wymagane
• obsługuje więcej typów relacji i pól

A poparcie dla JPA to przede wszystkim:

• bardziej popularne
• jdo nie żyje
• doesnt use bytecode enhancement

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

Widzę też sporo postów z Użytkownicy JDO, którzy przenieśli się do JDO i są z tego powodu o wiele szczęśliwsi.

Jeśli chodzi o to, że JPA jest bardziej popularne, wydaje się, że jest to częściowo spowodowane obsługą dostawcy RDBMS, a nie jest technicznie lepsze. (Dla mnie brzmi jak VHS/Betamax).

JDO i jego referencyjna implementacja Datanucleus wyraźnie nie jest martwy, o czym świadczy przyjęcie go przez Google do GAE i aktywny rozwój kodu źródłowego (http://sourceforge.net/projects/datanucleus/).

Widziałem liczba skarg na JDO z powodu rozszerzenia bajtowego kodu, ale nie ma jeszcze wyjaśnienia, dlaczego jest źle.

W rzeczywistości, w świecie, który staje się coraz bardziej opętany rozwiązaniami NoSQL, JDO (i implementacja datanucleus) wydaje się o wiele bezpieczniejsze.

Właśnie zacząłem używać JDO / Datanucleus i mam go skonfigurowany tak, że mogę łatwo przełączać się między za pomocą db4o i mysql. Dla szybkiego rozwoju pomocne jest użycie db4o i nie trzeba się zbytnio martwić o schemat DB, a następnie, po ustabilizowaniu schematu wdrożyć do bazy danych. Jestem również przekonany, że później mogę wdrożyć całą / część mojej aplikacji do GAE lub skorzystać z rozproszonej pamięci masowej / map-reduce a la hbase / hadoop / cassandra bez zbytniego refaktoryzacji.

Znalazłem początkową przeszkodę w rozpoczęciu pracy z Datanucleus trochę trudne-dokumentacja na stronie datanucleus jest trochę trudno dostać się do-samouczki nie są tak łatwe do naśladowania, jak chciałbym. Powiedziawszy bardziej szczegółowa dokumentacja dotycząca API i mapowania jest bardzo dobra po przejściu początkowej krzywej uczenia się.

Odpowiedź brzmi: to zależy, czego chcesz. Wolałbym mieć czystszy kod, no-vendor-lock-in, bardziej zorientowany na pojo, opcje nosql bardziej popularne.

Jeśli chcesz mieć ciepłe uczucie, że robisz to samo, co większość innych programistów/owiec, wybierz JPA / hibernate. Jeśli chcesz prowadzić w swojej dziedzinie, przetestuj JDO / Datanucleus i zrób swój weź się w garść.

Co proponujesz do nowego projektu?

Moje osobiste doświadczenie z Hibernate polega na tym, że czas zaoszczędzony z góry jest bardziej niż równoważony niekończącymi się dniami, które będziesz spędzać na próbach zrozumienia i debugowania problemów, takich jak nieoczekiwane zachowanie aktualizacji kaskadowych.

Jeśli używasz relacyjnego DB, to im bliżej jest Twój kod, tym bardziej masz kontrolę. Warstwa Dao sprężyny umożliwia precyzyjną kontrolę warstwy mapowania, jednocześnie eliminując potrzebę kodu boilerplate. Ponadto, integruje się z warstwą transakcyjną Springa, co oznacza, że możesz bardzo łatwo dodać (za pośrednictwem AOP) skomplikowane zachowanie transakcyjne bez tego ingerowania w kod(oczywiście dostajesz to również z Hibernate).

JDO nie żyje

JDO nie jest martwy, więc proszę sprawdzić swoje fakty. JDO 2.2 został wydany w październiku 2008 JDO 2.3 jest w fazie rozwoju.

Jest to rozwijane otwarcie, pod Apache. Więcej wydań niż miało JPA, a jego specyfikacja ORM jest jeszcze przed nawet proponowanymi funkcjami JPA2

JDO ma zaawansowane funkcje niż JPA zobacz http://db.apache.org/jdo/jdo_v_jpa.html

Używam JPA (implementacja OpenJPA z Apache, która jest oparta na bazie KODO JDO, która ma ponad 5 lat i jest niezwykle szybka/niezawodna). IMHO każdy kto ci każe ominąć specyfikację daje złe rady. Poświęciłem czas i zostałem zdecydowanie nagrodzony. Z JDO lub JPA możesz zmienić dostawców z minimalnymi zmianami(JPA ma mapowanie orm, więc mówimy o mniej niż dzień, aby ewentualnie zmienić dostawców). Jeśli masz 100 + tabele jak robię to jest ogromny. Plus masz wbudowane buforowanie z eksmisjami z pamięci podręcznej i to wszystko dobrze. SQL / Jdbc jest odpowiedni dla zapytań o wysokiej wydajności, ale transparent persistence jest o wiele lepszy dla pisania algorytmów i procedur wprowadzania danych. W całym systemie mam tylko około 16 zapytań SQL (50k + linijek kodu).

Każdy, kto mówi, że JDO nie żyje, to astroturfing FUD monger i oni o tym wiedzą.

JDO żyje i ma się dobrze. Specyfikacja jest nadal potężniejsza, dojrzała i zaawansowana niż znacznie młodsza i ograniczona JPA.

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

Sam się temu przyglądałem i nie mogę znaleźć silnej różnicy między tymi dwoma. Myślę, że duży wybór polega na tym, w jakiej implementacji korzystasz. Dla siebie rozważałem platformę DataNucleus , ponieważ jest to niezależna od przechowywania danych implementacja obu.

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

Przełączyliśmy się na hibernację. My bawiliśmy się tylko używaniem czystego JPA przez jakiś czas, ale musieliśmy użyć niektórych specyficznych funkcji Hibernate do mapowania. Uruchamianie tego samego kodu w wielu bazach danych jest bardzo proste. Hibernate wydaje się buforować obiekty agresywnie lub po prostu czasami ma dziwne zachowanie buforowania. Istnieje kilka konstrukcji DDL, które Hibernate nie może obsłużyć, a więc są one zdefiniowane w dodatkowym pliku, który jest uruchamiany w celu zainicjowania bazy danych. Kiedy napotkałem problem hibernacji często jest wiele osób, które natknąłem się na ten sam problem, który sprawia, że googling dla rozwiązań łatwiejsze. Wreszcie Hibernate wydaje się być dobrze zaprojektowany i niezawodny.

Niektórzy respondenci sugerowali użycie tylko SQL. Prawdziwym zabójczym przypadkiem użycia mapowania relacyjnego obiektów jest testowanie i rozwój. Bazy danych, które są zbudowane do obsługi dużych ilości danych, są zazwyczaj drogie i lub są trudne do zainstalowania. Są trudne do przetestowania. Istnieje wiele baz danych Java w pamięci, które mogą być używane do testowania z, ale są zazwyczaj bezużyteczne do produkcji. Możliwość korzystania z prawdziwej, ale ograniczonej bazy danych zwiększy produktywność i niezawodność kodu.

Zrobiłem przykładową WebApp w maju 2012, który używa JDO 3.0 & DataNucleus 3.0 - spójrz, jak czysty jest: https://github.com/TorbenVesterager/BadAssWebApp

Ok może to trochę za czyste, bo używam Pojo zarówno dla bazy danych jak i klienta JSON, ale jest fajnie:)

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