Witam,
Chcę napisać aplikację request based korzystając z backendu EJB. O ile wiem standard to słabo wspiera, nie licząc Servletow, ktore sa zbyt nisko poziomowe.
Zastanawiam sie nad Struts 2, gdyz Spring MVC jest zbyt mocno zintegrowany ze Springiem, co dostarczy tylko nadmiarowych zaleznosci i problemow z integracja, ktorych nie chce.
Jaki framework powinienem wybrac, aby sie nie napracowac przesadnie?
Idealnie byloby wstrzykiwac @ejb rownie latwo jak w JSF.
Pozdrawiam,
Do MVC najlepiej wykorzystać narzędzie do tego przeznaczone np. Play Framework.
Nie wiem z jakich powodów chcesz wykorzytywać EJB, ale jeśli musisz, to wszystko poza logiką biznesową możesz napisać w Playu (modele, widoki, kontrolery), a logikę napisać w EJB i wołać z Playa za pomocą RMI. Oczywiście wiąże się to z uruchominiem dwóch równoległych serwerów i aplikacji. Domyślny Netty dla Playa i np. jBoss dla kontenera EJB lub lżejsza wersja implementacji serwera JEE - TomEE.
Może wydawać się to przekombinowane, ale w praktyce nie powinno być większych problemów.
IMO jest to mega przekombinowane, gdyż chcę mieć interfejsy lokalne EJB. Już wolę użyć Spring MVC, gdyż nie potrzebuje dwóch serwerów aplikacji, musze jednak rejestrowac kazdy EJB jako Spring Bean za pomoca JNDI co mi sie nie podoba. Testowałem takie rozwiązanie, ale wydało mi się nieco zbyt skombinowane.
Podejrzewalem, ze Struts2 moze sie dobrze sprawdzic w takim zastosowaniu. Zalezy mi jednak na prostocie porywnywalnej z JSF2.
Ale właściwie po co ci tutaj EJB? Szczególnie jeśli chcesz olać jedną z nielicznych mocnych stron tej technologii czy obiekty remote.
Mam bardzo pozytywne doswiadczenie w programowaniu w zestawie EJB3.x + JSF 2.x. Po prostu wydaje mi sie to banalnie prostym sposobem na osadzenie logiki biznesowej, darmowej obslugi transakcji (JTA), latwosci integracji z JPA, timer service itp. Do tego bez zadnych problemow integrowalem to z innymi rozwiazaniami zamknietymi z bibliotekach niestandardowych.
Coz takiego mocnego jest w Springu (badz innych alternatywach), skoro EJB3 jest slabe? Przeciez wzglednie jest to podobna technologia, tylko nieustandaryzowana (o ile wiem JEE standaruzuje wiele najlepszych pomyslow, czesciej tych bardziej innowacyjnych ze Springa, dlatego dziala tak dobrze). Podaj prosze argumenty, na podstawe ktorych Twoim zdaniem EJB3 jest slabe. Super jesli beda to realne use-case.
Z drugiej strony Spring potrafi bardzo duzo, tez moge go uzyc do obslugi DAO (Spring Data) oraz wlaczyc JTA z serwera aplikacji.
W twoim przypadku rzeczywiście struts będzie dobrym wyborem.
Choć z EJB już nie pracuje od dawna......Spring ma o wiele więcej zaoferowania
A panowie powidzcie proszę na czym polega przewaga Springa nad EJB3, w zakresie funkcjonalnosci obslugiwanych przez oba frameworki?
EJB musi być odpalane na serwerze aplikacyjnym i ogólnie ma większy narzut na działanie. Ale tak poza tym to EJB + CDI daje porównywalne możliwości co Spring IoC. Minusem jest jednak to że JEE rozwija sie bardzo bardzo powoli. EJB 3.1 to jest 2009 rok, czyli 5 lat temu. Spring rozwija się dużo szybciej i bardzo szybko dodaje wsparcie dla nowych technologii.
Moim zdaniem to, ze JEE rozwija sie bardzo powoli to wielka zaleta tej technologii, gdyz dostarczana wygrzanych, sprawdzonych rozwiazan, a przemysl nie lubi przesadnych innowacji. Niech core rozwija sie powoli, ale konsekwentnie skoro wszystko inne mozna sobie niewielkim wysilkiem skonfigurowac. Dla mnie osobiscie dodawanie niestandardowych funkcjonalnosci np. raportowania, generowania dokumentoiw czy dowolnych dostepnych w bibliotekach jak np. wsparcie dla LDAP to nie jest zagadnienie: wystarczy dopiac odpowiedni jar.
Z drugiej strony nie mailem problemow z integracja rozwiazan opartych na EJB i GridFS/MongoDB czy innych bardziej innowacyjnych. Dziala po prostu swietnie, dzieki Mavenowi integracja bibliotek niestandardowych nie byla zagadnieniem. Przypuszczam, ze w Springu osiagnolbym to podobnym wysilkiem.
Czy posiadanie serwera aplikacji to jest duzy bol? Moim zdaniem nie, poniewaz pozwala to na lekkosc samego projektu, kosztem ciazaru serwera aplikacji. Kontener, ktory posiada wsparcie tylko dla servletow / JSP musi przeciez dociagnac wszystkie zaleznosci jak Spring MVC, Spring IoC, Spring Data i czesto dostawce JPA. Dlatego ''lekkosc' i mniejszy narzut mnie osobiscie nie przekonuje.
Tak naprawde za wyborem Springa do nowego projektu przemawiaja nastepne argumenty: lepsze wsparcie dla Javy 8 (wspomniana innowacyjnosc), dostep do frameworka MVC bez narzutow konfiguracyjnych. Z drugiej strony mialbym wiecej wysilku, aby skutecznie uruchomic JSF (z CDI bylby prawie na pewno problem).
Pytanie o dobry framework requestowy dla JEE wciaz jest aktualne jakby ktos mial jakis ciekawy pomysl. Kryterium to banalnosc integracji z EJB, na poziomie JSF. ;)
wystarczy dopiac odpowiedni jar.
Teoretycznie tak, ale często jednak łatwiej integruje się rozwiązania które maja spójne i ustandaryzowane API (np. korzystają z tych samych klas i nie trzeba sie bawić w mapowanie jednych klas na drugie etc).
Czy posiadanie serwera aplikacji to jest duzy bol? Moim zdaniem nie, poniewaz pozwala to na lekkosc samego projektu, kosztem ciazaru serwera aplikacji. Kontener, ktory posiada wsparcie tylko dla servletow / JSP musi przeciez dociagnac wszystkie zaleznosci jak Spring MVC, Spring IoC, Spring Data i czesto dostawce JPA. Dlatego ''lekkosc' i mniejszy narzut mnie osobiscie nie przekonuje.
Różnica jest taka że w Springu masz do kontenera załadowane to co ci potrzebne i już, a w serwerze aplikacyjnym masz załadowane wszystko, w tym masę komponentów które nie są ci potrzebne bo ich nie używasz :)
Z drugiej strony mialbym wiecej wysilku, aby skutecznie uruchomic JSF (z CDI bylby prawie na pewno problem).
Nie. Spring doskonale integruje się z JSFem i out-of-the-box wspiera JSFowe managed beany jako springowe beany :)
Nie. Spring doskonale integruje się z JSFem i out-of-the-box wspiera JSFowe managed beany jako springowe beany :)
Mam pewne doswiadczenie w integracji JSF i Spring. Zrobilem to korzystajac:
<application>
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver
</el-resolver>
</application>
W rezultacie moglem wstrzykiwac obiekty springa za pomoca settera oraz @ManagedProperty podajac nazwe obiektu za pomoca EL. Niestety dzialalo to tylko dla JSF Managaed Beans, a nie CDI beans. Rejestracja JSF ManagedBeans jako Spring Beans dzialala natomiast dosc marnie. Do tego dochodzil problem z dodaniem Custom Scope do JSF ViewScope. Mozna to zrobic, jednak jest to troche pod gorke.
Niestety nie udalo mi sie uruchomic stabilnego JSF z CDI oraz Springiem.
Byłbym niezmiernie wdzięczny gdybyś podesłał mi źródło o informacji JSF + Spring out-of-box.
O CDI nigdzie nie wspominałem i w ogóle wydaje mi się że to jakiś dziwny pomysł. Jeśli używasz Springa to także Spring IoC i próba łączenia tego z innym IoC (czym jest CDI) nie wydaje się sensownym pomysłem.
Faktem jest, ze rozwoj JSF idzie mocno w strone CDI, a z nastepnym wydaniem (po 2.2) ManagedBeans zostana uznane jako deprecated. Juz w tej chwili korzystajac z Managed Beans nie mam dostepu np. do FlowScoped (webflow w JSF).
Z drugiej strony moge wykorzystac do tego Spring WebFlow i tez bedzie ok, wiec w zasadzie az tak stratny nie jestem.
Mnie raczej zastanawia czy uzywanie Spring IoC w JSF ma sens. Ja mam co do tego watpliwosci. JSF ma w sobie dependency injection (wspomniane @ManagedProperty, ktore moze tez wstrzyknac np. Springowe repository czy dowolna backendowa usluge: Spring IoC uzywam wtedy w backendzie, a frontendem zajmuje sie tylko JSF). Moze jest prymitywne, ale czesto w zupelnosci wystarczajacego do obslugi prostego GUI (po co w GUI mi AoP poza standardowymi JSF-owymi interceptorami @PostConstruct, @PreDestroy?). A przeciez trzymanie logiki w JSF managed beanach to jest porazka i nie zawsze potrzeba tak skomplikowanej machiny jak Spring IoC/CDI. Moim zdaniem pozwala to utrzymac wieksza prostote projektu, a to tez jest wazne.
Aby uzyc Spring IoC i wykorzystac jego potencjal musialbym zarejestrowac JSF Managed Bean jako Spring bean (adnotacja lub XML). Do tego zarejestrowac JSF ViewScope jako Custom Scope. Dla mnie jest to porazka i przerost formy nad tresciowa, a nie Spring IoC + JSF out-of-the box.
Juz nie wspominam, ze jest troche roboty nad sama konfiguracja .jar (pom.xml), aby wszystko ze soba ladnie gadalo. Dlatego ciekawilo mnie wspomniane przez Ciebie out-of-box.