2011-01-09 13 views
11

Dotyczy aplikacji WWW Java EE, która będzie obsługiwana przez pełny serwer aplikacji Java EE, np. GlassFish, czyli najlepsze rozwiązanie ORM? EJB 3 lub Hibernacja 3 A dlaczego?EJB 3 lub Hibernate 3

+1

Istnieje wiele innych rozwiązań dotyczących trwałości, które mają wyraźne zalety; wydaje się, że zignorowałeś je w swoim pytaniu, a więc każda odpowiedź tego, co jest "najlepsze", jest arbitralna. Prawdopodobnie to, co najlepsze, zależy od samej aplikacji, programistów, którzy ją piszą, i magazynu danych używanego ... i nie podałeś informacji na temat tych – DataNucleus

Odpowiedz

27

Te dwie są zupełnie inne.

EJB3 jest modelem składowym i nie ma nic wspólnego z ORM. Pomaga w łatwym zarządzaniu transakcjami i zapewnia łatwy dostęp do menedżera jednostek z JPA, który jest standardowym rozwiązaniem ORM w Java EE.

Hibernate (3) jest w istocie roztwór ORM, jak zdarza się taki, który implementuje JPA.

Zatem bardziej logiczne pytanie brzmi: czy używać standardowych interfejsów JPA, czy bezpośrednio korzystać z interfejsu Core API Hibernate. Następnie można zadać pytanie, czy użyć autonomicznego JPA, czy w połączeniu z EJB 3.

Odpowiedź zależy trochę od tego, czego potrzebujesz dokładnie, ale zwykle używanie JPA w połączeniu z EJB 3 jest najłatwiejszym rozwiązaniem. Używanie standaryzacji JPA lub Hibernate wymaga znacznie bardziej szczegółowego kodu, a Ty musisz ręcznie zarządzać transakcjami, co może być uciążliwe.

JPA vs Hibernate to kolejna debata. WZP ma tę zaletę, że ma standardowe interfejsy, więc więcej programistów prawdopodobnie będzie z nim zaznajomionych. Z drugiej strony natywne interfejsy API Hibernate są zawsze super zestawami API i oferują więcej mocy.

Zazwyczaj programiści głównie opierać swój kod na WZP, a następnie korzystać z niektórych specyficznych Hibernacja adnotacje lub wywołań API, gdzie ma to sens. W 99,99% przypadków takie mieszane użycie API jest obsługiwane.

Należy pamiętać również, że GlassFish jest w zestawie z EclipseLink, nie z Hibernate. EclipseLink jest porównywalny z Hibernate, ale poprzedza go ponad dekadę. Hibernate zabrał dużo z EclipseLink (wtedy TopLink).

Zobacz również tę odpowiedź dałem podobnym pytaniem: Database table access via JPA Vs. EJB in a Web-Application

-1

Są podobne; specyfikacja 3.0 dla EJB miała wiele wspólnego z Hibernate i Spring.

Nie mam żadnych dokładnych danych, aby móc je zacytować, ale powiedziałbym, że jeśli akceptujesz GlassFish, rozsądnie jest korzystać z całej jego technologii. Po co wprowadzać kolejną zależność? Sprawdź, czy Glassfish może wykonać zadanie za Ciebie.

5

co pytasz jest API, które jest lepsze: EJB3 (JPA) lub hibernacji? Powiedziałem to, ponieważ pytasz o EJB3 JPA (który jest tylko API) i Hibernate (który jest implementacją i API). Aby porównać jabłka z jabłkami, musisz porównać interfejsy API. Możesz wybierać między standardowym (JPA) i mocniejszym zastrzeżonym API (Hibernate).

Ale wybierając JPA jest jeszcze jeden wybór: do jego realizacji. Wybierając Hibernate do wdrożenia, możesz zasadniczo odrzucić swoje pytanie, ponieważ zarówno JPA, jak i Hibernate są dostępne.

Więc pytanie zmieni: JPA realizacja które mam wybrać ... (między Hibernate, EclipseLink, OpenJPA, DataNucleus, itp.)?

+0

Należy pamiętać, że * EJB3 (JPA) * może być trochę mylące. Sugeruje to, że EJB3 to inna nazwa WZP, ale tak nie jest. Była to technicznie całkowicie oddzielna specyfikacja w EJB 3.0 i została sformalizowana w obecnej 3.1 wersji EJB. JPA nie jest technicznie i organizacyjnie kompletną inną specyfikacją. W żaden sposób nie możesz zmienić warunków. –

+0

Wszystko, co miałem na myśli, to podążanie za terminologią w pytaniach Ehsuna. Dzięki za wyjaśnienia. – topchef