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?
Odpowiedzi:
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).
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 .
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.
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.
Próbowałeś czegoś? Czy napotkałeś jakiś szczególny problem? Znowu brzmi to jak bezpłatne roszczenie.
źródło
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).
źródło
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).
źródło
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.
źródło
Teraz, po pewnym czasie, mam doświadczenie ze stosami:
Moje wyniki to:
źródło
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 ”
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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).
źródło
Poleciłem Wam Tomcata ze Springiem, ponieważ:
Warto wybrać Tomcat, ponieważ nie potrzebujesz żadnego ciężkiego przetwarzania
źródło