Java EE 6 kontra Spring 3 stack [zamknięty]

Rozpoczynam teraz nowy projekt. Muszę wybrać technologie. Potrzebuję czegoś lekkiego, więc nie ma EJB ani Seam. Z drugiej strony potrzebuję JPA (Hibernate lub alternatywa) i JSF z IceFaces.

Czy uważasz, że taki stos w Spring 3 wdrożony na Tomcat to dobry wybór? A może aplikacja internetowa Java EE 6 mogłaby być lepsza? Obawiam się, że Java EE 6 to nowa technologia, jeszcze niezbyt dobrze udokumentowana. Tomcat wydaje się być łatwiejszy w utrzymaniu niż Glassfish 3.

Jaka jest Twoja opinia? Czy masz jakieś doświadczenia?

Potrzebuję czegoś lekkiego, więc nie ma EJB ani Seam.

Czy mógłbyś wyjaśnić, co sprawia, że ​​EJB są ciężkie od czasu EJB3? Czy zdajesz sobie sprawę, że nie jesteśmy już w 2004 roku? Naprawdę chciałbym przeczytać twoją definicję światła i twoje argumenty (iz przyjemnością zaktualizuję swoją odpowiedź, ponieważ jestem prawie pewien, że chciałbym powiedzieć kilka solidnych rzeczy).

Z drugiej strony potrzebuję JPA (Hibernate lub alternatywa) i JSF z IceFaces.

Java EE 6 Web Profile, który obejmuje JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... byłby do tego idealny i możesz użyć GlassFish v3 Web Profile, aby uruchomić aplikację zbudowaną z Java EE 6 Web Profile .

Czy uważasz, że taki stos na Spring 3 wdrożony na Tomcacie to dobry wybór? A może aplikacja internetowa Java EE 6 mogłaby być lepsza?

Cóż, podoba mi się pomysł uruchamiania mojego kodu na niezastrzeżonej platformie (Java EE), a nie na zastrzeżonym kontenerze (Spring). Myślę, że Java EE 6 jest wystarczająco dobra (i to jest eufemizm, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Zauważ, że byłem sceptykiem JSF, ale przyjrzałem się ponownie i JSF 2.0 z CDI jest tak inny, że nie mogę nawet porównać. A jeśli nie spojrzałeś na CDI, powiem ci, że to rządzi.

Obawiam się, że Java EE 6 to nowa technologia, jeszcze niezbyt dobrze udokumentowana.

Java EE wygląda na całkiem dobrze udokumentowaną. To brzmi jak darmowe roszczenie. Wierz mi lub nie, ale zaczynam uważać, że Spring się komplikuje, a Java EE staje się łatwiejsza.

Tomcat wydaje się być łatwiejszy w utrzymaniu niż Glassfish 3.

Próbowałeś czegoś? Czy napotkałeś jakiś szczególny problem? Znowu brzmi to jak bezpłatne roszczenie.

Nie korzystałem z JavaEE6.

Jednak wszystkie poprzednie wersje JavaEE i EJB dostały mnie na tyle mocno, że nie będę mu ufać, dopóki nie ustali się jako de facto standardu, a nie tylko de iure. Obecnie wiosna nadal jest de facto standardem.

Oszukałeś mnie raz hańba ci. Oszukaj mnie dwa razy, wstyd mi. Oszukaj mnie trzy razy, EJB.

Niektórzy twierdzą, że Spring jest zastrzeżony. Twierdziłbym, że implementacje specyfikacji JavaEE przez dostawców były równie zastrzeżone, jeśli nie bardziej.

Niedawno przeszedłem dużą konwersję, przenosząc kilka aplikacji Java z JBoss do Weblogic. Wszystkie aplikacje Spring / Hibernate zostały przeniesione bez modyfikacji, ponieważ miały wbudowane wszystkie potrzebne biblioteki. Wszystkie aplikacje, które korzystały z JPA, EJB i JSF, były katastrofą. Subtelne różnice w interpretacji JPA, EJB i JSF między serwerami aplikacji powodowały różnego rodzaju paskudne błędy, których naprawa trwała wieczność. Nawet coś tak prostego jak nazewnictwo JNDI było zupełnie inne w przypadku serwerów aplikacji.

Wiosna to realizacja. JavaEE to specyfikacja. To jest OGROMNA różnica. Wolałbym użyć specyfikacji, JEŚLI specyfikacja była w 100% szczelna i nie dawała absolutnie żadnego miejsca na poruszanie się w sposobie, w jaki sprzedawcy wdrażają tę specyfikację. Ale specyfikacja JavaEE nigdy nie była taka. Może JavaEE6 jest bardziej szczelna? Nie wiem Im więcej możesz spakować w swoim WAR i im mniej polegasz na bibliotekach AppServer, tym bardziej przenośna będzie twoja aplikacja i to jest w końcu powód, dla którego używam Javy, a nie Dot-NET.

Nawet JEŚLI specyfikacja była szczelna, byłoby miło móc zaktualizować serwer aplikacji bez konieczności aktualizowania wszystkich moich stosów technologicznych we wszystkich moich aplikacjach wraz z nim. Jeśli chcę zaktualizować JBoss 4.2 do JBoss 7.0, muszę wziąć pod uwagę wpływ nowszej wersji JSF na wszystkie moje aplikacje. Nie muszę brać pod uwagę wpływu na moje aplikacje Spring-MVC (lub Struts).

To nie ma znaczenia. Java EE 6 jest wystarczająco dobra i ze względu na dostępne tam profile nie jest „ciężka” - będziesz po prostu używać profilu internetowego.

Osobiście wolę wiosnę. Ale wyczerpują mi się racjonalne argumenty przeciwko Java EE 6 :)

(Jak przypomniał mi komentarz - możesz wypróbować RichFaces , a także ICEfaces i / lub PrimeFaces - w zależności od potrzebnych komponentów).

Niedawno jeden z moich klientów dotyczył oceny Spring Stack Vs Custom Framework w porównaniu ze standardami Java EE. Po miesiącu testów i prototypów nie tylko byłem zadowolony, ale też zachwycił mnie zestaw funkcji Java EE 6. W przypadku każdej nowej architektury projektu „korporacyjnego” w 2011 roku i w przyszłości wybrałbym Java EE 6 i potencjalne rozszerzenia, takie jak Seam 3 lub nadchodzący projekt rozszerzeń Apache JSR299. Architektura Java EE 6 została usprawniona i łączy w sobie najlepsze z wielu pomysłów open source, które ewoluowały w ciągu ostatnich kilku lat.

Rozważ następujące funkcje po wyjęciu z pudełka: zarządzanie zdarzeniami, konteksty i DI, przechwytywacze, dekoratory, usługi sieciowe REST, zintegrowane testowanie z wbudowanym kontenerem, zabezpieczenia i wiele innych.

Większość moich wyników jest publikowana na moim blogu, wyjaśniając kluczowe pojęcia Java EE 6, które mogą okazać się przydatne.

Oczywiście nie ma sztywnej zasady wyboru frameworka. Java EE 6 może być dobrze rozbudowana w przypadku prostszych „witryn internetowych”, które nie wymagają rozbudowanego stanu sesji konwersacyjnej. Równie dobrze możesz wybrać Grails lub Play! Struktura. Ale w przypadku konwersacyjnych aplikacji internetowych nie widzę lepszego argumentu, dlaczego Java EE 6 nie jest dobrym rozwiązaniem.

Teraz, po pewnym czasie, mam doświadczenie ze stosami:

• Java EE 5 + Seam + GraniteDS + Flex
• Wiosna 3 + Vaadin (na GWT)
• Wiosna 3 + JSF 2.0 (PrimeFaces)

Moje wyniki to:

• Spring 3 jest znacznie prostszy niż Seam (prawie Java EE 6) i działa na Tomcat i Jetty! (Przystań do rozwoju z wtyczką maven to szkoda).
• Uwielbiam Flex (tak naprawdę byłem programistą Flex przez długi czas, więc jestem stronniczy) i jeśli potrzebujesz bogatego interfejsu i możesz kupić FlashBuilder, użyj tego, ale użyj tego, który backend Spring + GraniteDS lub BlazeDs. Jeśli nie możesz kupić FlashBuildera, nie trać czasu.
• Vaadin jest świetny !. Proces programowania jest prostszy niż Flex, ale możesz łatwo tworzyć rozbudowane aplikacje bez bałaganu HTML. Nie napiszesz ani jednej linii JS. Potrzebujesz tylko CSS (w Flex też go potrzebujesz). Jeśli więc interfejs Twojej aplikacji będzie zachowywał się jak aplikacja desktopowa i nie możesz (lub nie chcesz) używać Flex - użyj Vaadin. Ostrzeżenie! Vaadin ma duże obciążenie JS dla przeglądarki.
• Jeśli tworzysz prostszą aplikację podobną do strony internetowej, użyj JSF2.0 (z zapleczem sprężynowym jak powyżej). Będziesz musiał walczyć z HTML (nienawidzę tego), a tworzenie bogatego interfejsu będzie trudniejsze niż w Vaadin (zwłaszcza układy). Otrzymasz lekki HTML dla wolniejszych przeglądarek / komputerów. Lubię PrimeFaces - to łatwe i dobrze udokumentowane. Drugie miejsce to IceFaces
• Jeśli tworzysz stronę internetową (NIE aplikację internetową), w której chcesz tchnąć życie w HTML (zamiast tworzyć aplikację korporacyjną, która pasuje do przeglądarki), użyj Wicket (jeśli wolisz oparty na komponentach, nastawienie pull) lub SpringMVC (jeśli wolisz oparty na szablonie , nastawienie pchania) lub po prostu użyj Play! struktura. Pamiętaj, że tworzenie bogatych komponentów opartych na danych będzie znacznie trudniejsze, ale będziesz mieć kontrolę nad każdym tagiem HTML (Twój projektant HTML / Graphics pokocha to)

Przeczytaj artykuł Adama Bien's Future Of Enterprise Java ... Is Clear (Java EE z / bez Spring i Vice Versa) , w tym komentarze, aby uzyskać obie strony medalu. Sprężynę wybiorę z kilku powodów, a jeden z nich to kolejny (powielając jeden z komentarzy z postu)

„Nie jestem pewien, o którym serwerze Java EE 6 mówisz. Posiada certyfikat Glassfish i TMAX JEUS. Zajmie trochę czasu (czytaj: lata), zanim wersje WebSphere, WebLogic, JBoss itp. Zgodne z Java EE 6 będą w produkcji i będą mogły być używane w rzeczywistych aplikacjach. Spring 3 potrzebuje tylko Java 1.5 i J2EE 1.4, więc może być z łatwością używany w prawie wszystkich środowiskach ”

Moja opinia jest oparta na czymś, o czym inni nie wspominali, a mianowicie na tym, że kod w mojej pracy ma tendencję do życia przez dziesięciolecia (dosłownie), dlatego utrzymanie jest dla nas bardzo ważne. Utrzymanie własnego kodu i bibliotek, z których korzystamy. Kontrolujemy własny kod, ale w naszym interesie jest, aby biblioteki, z których korzystamy, były utrzymywane przez innych w wyżej wymienionych dekadach lub dłużej.

Krótko mówiąc, doszedłem do wniosku, że najlepszym sposobem na osiągnięcie tego jest użycie implementacji specyfikacji firmy Sun o otwartym kodzie źródłowym, aż do surowej maszyny JVM.

Spośród wdrożeń open source, Apache Jakarta dowiodło, że utrzymuje swoje biblioteki, a ostatnio Sun wykonał dużo pracy w tworzeniu wysokiej jakości wdrożeń dla Glassfish v3. W każdym razie mamy również źródło dla wszystkich modułów, więc jeśli wszystko inne zawiedzie, możemy sami je utrzymać.

Specyfikacje firmy Sun są zwykle bardzo rygorystyczne, co oznacza, że ​​implementacje zgodne ze specyfikacją można łatwo wymieniać. Wystarczy spojrzeć na kontenery serwletów.

W tym konkretnym przypadku sugerowałbym przyjrzenie się JavaServer Faces po prostu dlatego, że jest częścią Java EE 6, co oznacza, że ​​będzie dostępny i utrzymywany przez bardzo, bardzo długi czas. Następnie zdecydowaliśmy się rozszerzyć o MyFaces Tomahawk, ponieważ daje kilka przydatnych dodatków i jest to projekt Dżakarty.

Nie ma nic złego w JBoss Seam lub innych. Po prostu koncentrują się mniej na kwestii utrzymania, która jest dla nas tak ważna.

Widzę, jak używać Springa, jeśli już go masz, ale po co w nowym projekcie? Poszedłbym bezpośrednio z Java EE 6 (ejb3, jsf2.0 itp.)

Jeśli klientowi odpowiada Flex, zrób to. Użyj BlazeDS lub podobnego - bez MVC. Możesz poświęcić więcej czasu na tę część (wymianę danych między serwerem a klientem), ale masz pełną kontrolę po obu stronach.

Nie używaj Vaadin, chyba że chcesz zabić swoją przeglądarkę. Ponadto, gdy strony stają się bardziej złożone, poświęcasz więcej czasu na obejście kodu. Ponadto twój sposób myślenia będzie wymagał całkowitej zmiany, a wszystko, co wiesz o standardowym programowaniu front-endu, będzie marnotrawstwem. Argument, że nie musisz używać HTML lub JS, nie ma większego sensu. Nadal musisz to wiedzieć, nawet jeśli go nie używasz. Ostatecznie renderuje się do HTML i JS. Następnie spróbuj go zdebugować - upewnij się, że masz kilka dni na proste rzeczy. Poza tym nie mogę sobie wyobrazić programisty, który nie zna html / js.

Po prostu nie rozumiem, dlaczego ludzie próbują wszystkich tych abstrakcji zamiast bezpośrednio używać Java EE.

Dlaczego w 2010 roku wciąż krążą plotki, że EJB jest w wadze ciężkiej? Wygląda na to, że ludzie nie są aktualizowani w technologiach Java EE. Po prostu wypróbuj, będziesz mile zaskoczony, jak upraszcza się rzeczy w Java EE 6.

Odpowiedź na Twoje pytania zależy od wymagań projektu. Jeśli nie potrzebujesz funkcji Java EE, takich jak kolejki wiadomości, globalne transakcje zarządzane przez kontener itp., Wybierz tomcat + spring.

Również z doświadczenia odkryłem, że projekty, które wymagają dużej integracji usług internetowych, planowania i kolejek wiadomości, najlepiej wykonywać przy użyciu części stosu Java EE. Dobrą rzeczą jest to, że korzystając ze Springa możesz nadal integrować się z modułami Java EE działającymi na serwerze aplikacji.

Java EE 6 bardzo różni się od poprzednich wydań i naprawdę ułatwia wszystko. Java EE 6 łączy w sobie najlepsze pomysły ze zróżnicowanej społeczności Java - na przykład Rod Johnson ze Spring był aktywnie zaangażowany w tworzenie Dependency Injection JSR w Java EE 6. Korzyścią z używania Java EE 6 jest to, że programujesz zgodnie z standard, który może być ważny w niektórych organizacjach w zakresie wsparcia dostawcy itp.

GlassFish v3 obsługuje Java EE 6, jest dość lekki i uruchamia się bardzo szybko. Używałem Glassfish v3 do moich opracowań i jest naprawdę łatwy w konfiguracji. Jest wyposażony w bardzo przyjazną dla użytkownika konsolę administracyjną, która umożliwia graficzne administrowanie serwerem.

Jeśli używasz GlassfishV3 i JSF 2, możesz skorzystać z funkcji CDI Java EE 6, które pozwalają łatwo tworzyć konwersacje (np. Strony przypominające kreatora) w JSF.

Mimo to, używanie Java EE 6 wymaga również nauczenia się nowego API. W zależności od dostępnych ram czasowych może to nie być najlepszy wybór dla Ciebie. Tomcat istnieje od wieków, a kombinacja tomcat + spring została przyjęta w wielu projektach internetowych, co oznacza, że ​​istnieje mnóstwo dokumentacji / forów.

Pracowałem zarówno w Spring, jak i Java EE 6. Z mojego doświadczenia mogę powiedzieć, że jeśli wybierasz stary JSP lub prawnie zastrzeżony Flex, jesteś bezpieczny, jeśli pozostaniesz w Spring.

Ale jeśli chcesz iść naprzód z JSF, to czas przejść na Java EE 6. Z Java EE 6 przechodzisz do Facelets oraz standardowych bibliotek skryptów i bibliotek komponentów. Koniec z niezgodnościami skryptów i macierzami bibliotek komponentów.

Jeśli chodzi o Spring MVC, jest to dobre, o ile twój projekt nie rozrasta się zbytnio. Jeśli jest to ogromna aplikacja dla przedsiębiorstw, trzymaj się Java EE 6. Ponieważ tylko w ten sposób można zarządzać własnymi bibliotekami komponentów i pakietami zasobów w uporządkowany sposób.

Jeśli potrzebujesz pełnego stosu Java EE, polecam GlassFish 3.1. Uruchamia się bardzo szybko w porównaniu do innych kontenerów Java EE, które implementują część lub całość Java EE 6 (JBoss 6, WebLogic 10.3.4), ponowne wdrażanie zajmuje kilka sekund i prawie wszystko można zrobić przez konwencję zamiast konfiguracji, jest bardzo przyjazny.

Jeśli chcesz czegoś „lekkiego”, możesz dostosować Apache Tomcat 7.x do żądanych funkcji. Dużo używałem z następującymi bibliotekami: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - tylko lokalne transakcje zasobów JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Byłem programistą Java EE przez ostatnie 10 lat (cierpię na wczesne EJB, JSF i technologie internetowe), Java EE 6 jest bardzo łatwa, dobrze połączona, a obecny sprzęt działa płynnie, więc oryginalne powody, dla których motywowany Spring nie jest już ważny.

Nadal wolę wiosnę.

I pominąłbym JSF. Myślę, że to martwa technologia. Spring MVC byłby lepszą alternatywą. Więc Flex. Pomyśl w kategoriach umowy o pierwsze usługi XML i możesz całkowicie oddzielić zaplecze od interfejsu użytkownika.

Poleciłbym Spring + Tomcat, chyba że możesz poczekać, aż Glassfish v3 i Weld staną się bardziej dojrzałe. Obecnie występuje kilka problemów z zużyciem pamięci / obciążeniem procesora podczas uruchamiania Glassfish z aplikacjami obsługującymi CDI.

Nie przeczytałem wszystkiego, ale tylko po to, aby powiedzieć, że możesz teraz używać EJB3 w wojnie na Javie EE 6, więc możesz używać EJB3 na Tomcat (tak mi się wydaje).

Poleciłem Wam Tomcata ze Springiem, ponieważ:

1. Spring może tworzyć fasolki podkładowe dla JSP
2. Sprężyna będzie używana do utrwalania obiektu przez JPA

Warto wybrać Tomcat, ponieważ nie potrzebujesz żadnego ciężkiego przetwarzania