Czy preferuje się Spring + Hibernate zamiast EJB 3?

Moim zdaniem za każdym razem, gdy rozpoczynają się nowe projekty JEE (tam, gdzie te technologie będą miały zastosowanie), ludzie wolą używać kombinacji Spring + Hibernacja zamiast EJB 3.

Wydaje się, że młodszym programistom zaleca się skorzystanie z tego zamiast EJB.

Czy są to osobiste preferencje, czy istnieją uzasadnione powody? (np. blizny osobiste utworzone we wcześniejszych wersjach EJB, które spowodowały brak zaufania do EJB lub rozdęcie technologii w porównaniu z przyczynami wydajności lub krzywą uczenia się)?

Frameworki EJB 3+ są naprawdę całkiem dobre, ponieważ zostały dostarczone wraz z JPA jako odpowiedzią na skonfigurowane frameworki Persistence skonfigurowane, a także CDI, który pozwala na wstrzykiwanie zależności skonfigurowanych z adnotacjami. Dodajesz także na górze tego Spawu. Z drugiej strony wiosna nadrabia zaległości w konfiguracji dzięki adnotacji.

Biorąc to pod uwagę, historyczne wycofanie się z EJB1 i 2 nie powinno być pomijane. Oni nie tylko nie rozwiąże problemów z pisaniem aplikacji korporacyjnych, one spektakularnie nie powiodło się. Projektanci zorientowali się, jakie problemy napotykają twórcy aplikacji korporacyjnych i aplikacji internetowych, a tym samym nie dostarczyli rozwiązań, których naprawdę potrzebowali.

Dodaj do tego nieufność, że w obecnym kierunku Java są pewne poważne wstrząsy i niestabilności oraz brak wiary w obecnych zarządców i właścicieli starej Sun JVM w Oracle. Wiele osób nie wierzy, że Oracle poprawi Javę i poprowadzi ją, a także obawia się, że Apache Software Foundation może po prostu rzucić ręcznik. Coraz więcej osób szuka OpenJDK na przyszłość Javy, ale nie jest to miejsce, w którym powinno być do przyjęcia Enterprise.

Niektórzy postrzegają to wszystko jako zapach śmierci, ponieważ aplikacje korporacyjne są głównymi powodami, dla których Java była od dawna najlepszym językiem programowania na świecie. Właśnie dlatego Microsoft zdobywa tak wiele w stosunku do Javy dzięki technologiom .NET.

Twórcy aplikacji Java, którzy nie są przedsiębiorstwami, zwracają się coraz bardziej w stronę OpenJDK i innych platform open source, aby pomóc w tworzeniu swoich rozwiązań, a niektórzy nigdy nie patrzą wstecz. Można powiedzieć, że jest to zbyt mało, by przywrócić JEE na czele legalności, mimo że technicznie JEE może i stoi na nogi z twoją porównywalną aplikacją Spring.

EJB ma dużo bagażu. Część tego bagażu wynika z faktu, że był on skierowany do niewłaściwych odbiorców. Drugą częścią było to, że dwie pierwsze wersje były kompletnie badziewne.

Jeśli spojrzysz na oryginalne wersje EJB, projekt polegał na tym, że programista EJB mógłby stworzyć zapakowane rozwiązanie, które można by wykorzystać w dowolnym kontenerze zgodnym z EJB. W przypadku sklepu domowego ten poziom abstrakcji był niepotrzebny. Było to idealne rozwiązanie, aby stworzyć kwitnący rynek dla zewnętrznych dostawców komponentów EJB. Jednak dostawcy kontenerów byli nadgorliwi w marketingu i sprawiali, że tony sprzedawały swój produkt jako realne rozwiązanie dla codziennego rozwoju. Byłoby to równoważne z budowaniem całego kodu aplikacji jako składników COM +.

Aby uzyskać więcej informacji na temat oryginalnej specyfikacji J2EE, większość zaangażowanych dostawców miała serwery CORBA i chciała wykorzystać te produkty w przyszłości. Specyfikacja EJB została zbudowana w oparciu o protokół IIOP (w rzeczywistości Java RMI, która była cienką warstwą w stosunku do IIOP). CORBA została już odrzucona z powodu swojej złożoności, a EJB był po prostu CORBA w przebraniu, więc przyniósł ze sobą wiele problemów, które miał CORBA. W rzeczywistości abstrakcje EJB utrudniały pracę z czystą implementacją CORBA.

Gdy guma uderzyła w chodnik, ludzie zdali sobie sprawę, że wydajność EJB była okropna. Ponieważ każde połączenie jest zdalne, a trudności z uruchomieniem i poprawnym uruchomieniem aplikacji na początku, ludzie szybko szukali alternatyw. Rozwiązaniem stały się Hibernacja i Wiosna działające w kontenerze JSP.

EJB 3 „przyjął” to podejście. Ale nadal jest to ogólny kompromis, który nie zapewnia dużych korzyści. Nadal nie ma zewnętrznego rynku komponentów EJB, więc naprawdę nie ma sensu używać kontenera EJB do budowy swojego rozwiązania.

Krótko mówiąc. Chociaż EJB 3 stanowi znaczną poprawę w stosunku do dwóch pierwszych iteracji, nadal nie zapewnia wystarczających korzyści, aby przewyższyć koszty.