Spring MVC i JSF - korzystniejsze rozwiązania

0

Witam
Ostatnio mając chwile wolnego pomyślałem, żeby przejrzeć ogłoszenia o prace. Nie szukam póki co żadnej, jednak chciałem się dowiedzieć czego pracodawcy wymagają od developera javowego - inaczej mówiąc: co teraz jest na czasie, w czym sie pisze aplikacje. Z tego co tam widze, oprócz znajomosci jakiejs implementacji JPA typu Hibernate itd. dość (bardzo) często pojawia się Spring Framework.

Jako, że ostatnimi czasy zajmuje się JSF, doczytałem, że Spring MVC generalnie służy do tego samego, tylko jest konkurencyjną technologią.
JSF jest dla mnie (oprócz podstaw tj. servlety, jsp, jstl) pierwszym frameworkiem webowym, więc wiadomo początki są "gjentkie", ale jakoś leci :).

Zastanawiam się jednak czy Spring nie byłby lepszym wyborem? Przeglądając spis techonologii, ktore oferuje Spring, a w dodatku ze świadomością, że świetnie one ze soba współgrają wydaje sie na prawde warte uwagi. Nie chodzi mi tutaj o to, żebym "coś umiał jak pracodawca bedzie chciał", ale zwyczajnie z tego co widze wiele technologii tworzone jest tak, żeby współgrać ze Springiem. Jeszcze co do ogłoszeń, mało na którym jest napisane, że wymagania to np. CDI do dependency injection. Z tego co mnie słuch dochodzi najlepsze DI jest właśnie w Springu. (jak i wiele, wiele innych rzeczy - i do tego właśnie dążę)
Minusem z tego co mi wiadomo jest: brak komponentów tj. Primefaces dla JSF (do nauki dochodzi jQueryUI czy inne Javascriptowe kowadło) oraz to, że do pisania w Spring MVC potrzeba znajomości innych technologii springa tj. IoC lub własnie DI.

Generalnie to w czym się będzie przyjemniej pisało? Wiadomo, że każdy ma jakieś tam swoje gusta i upodobania, ale pewne schematy utarte dla danej technologii zostają i zastanawiam się jak wyglada wasza opinia :)

JSF z niektórymi technologiami Springa z tego co czytałem się może łączyć, z tym że Springiem nigdy sie nie bawiłem i nie wiem z którymi i w jaki sposób. Cały stos Springowy jest wszech i wobec chwalony w internecie i myśle czy nie lepiej sie brać za niego zamiast za "standardowe" JEE?

Po prostu myśle, które z tych narzedzi jest przyjemniejsze, potężniejsze i bardziej pożądane? Któremu warto poświęcić wiecej uwagi "dziś"?

Prosze o wyrozumiałość :) dość nowy w temacie jestem, moge się dużo mylić, z góry dziekuje
pozdrawiam!

1

Pytanie z serii "narty czy rower" ;) I jedno i drugie jest dobre, w danej sytuacji. Jeśli w jakimś ogłoszeniu piszą o JEE (i ani słowa i Springu) to w domyśle pewnie wymagają znajomości CDI ;)

0

Z tym, że jak sie patrzy na te ogłoszenia to w 8/10 jest mowa o Spring'u, a w 2/10 o JEE - przynajmniej ja tak zauważyłem.
To może pare pytań, bo nie umiem się wyrazić :P :

  1. Może ktoś by chciał opisać pokrótce co do czego jest dobre?
  2. Jakich technologii Spring'a mozna użyć wraz z JSF?
  3. Jeśli mowa w ogłoszeniu o JEE to zawiera się w tym min. CDI i co jeszcze?
  4. Doswiadczony developer javowy powinien znać i stos Spring'a i JEE? czy raczej oba "rozpoznawać" ale w jednym być na prawde dobrym?
  5. Która z tych technologii lepsza byłąby na start? wiadomo jak to początki, nie wszystko chce wejść do głowy chociaż napisane czarno na białym.
  6. (edit) I jeszcze jedno: Springowy stos służy nie tylko do tworzenia aplikacji webowych, ale do różnych desktopów, urzadzen wbudowanych, (może android?) również?

Zastanawia mnie po prostu poziom "fajności pisania" miedzy tymi technologiami. JSF z tego co mi sie wydaje będzie dobrze grał z całym stosem JEE, natomiast Spring MVC jak wiadomo ze stosem Springowym. Takie przeczucie jakby JEE odchodziło do lamusa, a Spring wchodził jako numer jeden :D czy się mylę?

2
  1. Właściwie obu stosów można użyć w dowolnym kontekście. JEE wymaga serwera aplikacyjnego a Spring nie, więc teoretycznie Spring może być użyty w "lżejszych" aplikacjach, na kontenerze serwletów dopakowanym bibliotekami. W przypadku serwera aplikacyjnego masz wszystko (narzucone ;) chociaż można zmienić) out of the box.
  2. Można użyć springowego IoC
  3. Zapewne stos JEE http://pl.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Standardowe_API
  4. Spring nie ma wszystkiego i często korzysta się z "best of both worlds". Zupełnie normalne są rozwiązania np. Spring + JPA + JTA + JAX-WS
  5. Dla desktopu? Tak, jesli chcesz możesz kontener odpalić w trybie standalone wiec teoretycznie tak. Na Androidzie nie.

Spring na pewno staje się bardzo popularny, ale ma on pewne plusy i minusy ->
Spring nie jest standardem, tylko konkretną technologią. JEE to standard, więc możesz wybrać jedną z wielu implementacji. Zmiany w Springu wynikają z inwencji twórców. W przypadku JEE masz community process.
Oznacza to że Spring może rozwijać się szybciej, ale może też być mniej "stabilny". W efekcie na przykład banki chyba wolą siedzeć na JEE ;)

0

A co z Spring Security + JSF? :P słyszałem, że też się da
Czyli jeśli stos JEE zawiera np. JPA - to w samym JPA nie da rady obsłużyć relacyjnych baz danych, tylko żeby to zrobić trzeba użyc implementacji tego JPA czyli np. Hibernate? na tej zasadzie?

lepiej robić źle cokolwiek, niż dobrze nie robić nic, w związku z tym poznaje JSF, ale mam do tego pewne obiekcje, nie wiem czy słuszne :) nie stane się javowym-nieudaniczkiem jak będe brnął w JEE? Czasami mam wrażenie jakby bez znajomości Springa w developerce javowej nie miało się czego szukać

@Edit
Generalnie to jeśli chodzi o JSF z moich spostrzeżeń dość niewiele jest tam czystego kodu javowego. Wiekszość to tagi, adnotacje, pliki xml'owe itp. Na filmach z wykładów na yt (typu jak unikać if - confitury itp) widzę, że często pisza dużo kodu czysto javowego, (coś o transakcjach, co kolwiek to jest, encjach itd.) Więc myśle sobie: skoro oni używają technologii gdzie kodzą typowo javą, ja takich gdzie używam tagów to może nie w te strone ide co trzeba? ;)

Tyle tych różnych technologii, że na prawde nie wiadomo za co się brać..

1
  1. Samo JPA to tylko zestaw interfejsów i konwencji, nic więcej. Tak samo jak JDBC to są tylko interfejsy. Za pomocą gołego JDBC z niczym sie nie połączysz bo nie ma tak "funkcjonalnego kodu". Musisz użyć jakiejś oferowanej implementacji :)
  2. Trudno mi powiedzieć, bo ja jestem trochę bardziej po Springowej stronie ;) JEE jest fajne dla dużych, szczególnie rozproszonych aplikacji. Spring takich możliwości nie ma -> nie da rady odpalić tej samej aplikacji na sklastrowanych serwerach i migrować między nimi użytkowników w zupełnie transparentny sposób. Tak samo nie ma out-of-the-box możliwości odpalania cześci komponentów na różnych maszynach w celu równoważnia obciążenia :) Inna sprawa że tylko duże aplikacje tego potrzebują ;]

Jeśli chodzi o JSF to przecież to jest tylko frontend. W Spring MVC tez musisz ten frontend zrobić i to też będzie html/ftl/velocity + jquery zamiast komponentów jsfa ;]

1

Spring Security i JSF nie ma żadnego problemu, korzystam i ma się świetnie.
W JSF kod javowy to będą głównie backing beany (nie wiem jak to po polszemu wyrazić), czyli tak np. obsługa logowania, rejestracji, generalnie większości rzeczy.
Sam uczę się JSFa, ale plan jest taki, żeby po skończeniu projektu przepisać go korzystając głównie ze springa wystawiając rest

0

@Shalom 1.czyli tak, są dwa frameworki: JSF (MVC) i Spring MVC (oba sa modelami MVC). W JSF frontend zrobie za pomoca Primefaces/Icefaces/Richfaces, natomiast w Spring MVC frontend zrobie tak jak mówisz np: html+jQuery?
Bo rozumiem tak jakbyś mówił ze JSF jest od frontendu, a z tego co mi wiadomo to jest framework MVC - czyli tak jak spring MVC. Dobrze to rozumuje (to dla mnie ważne)? :D

Samo JPA to tylko zestaw interfejsów i konwencji, nic więcej. Tak samo jak JDBC to są tylko interfejsy. Za pomocą gołego JDBC z niczym sie nie połączysz bo nie ma tak "funkcjonalnego kodu". Musisz użyć jakiejś oferowanej implementacji :)

  1. Czyli jeśli łączę się w prosty sposób z MySQL/SQLite (tj. tutaj: http://javastart.pl/zaawansowane-programowanie/bazy-danych-sqlite-w-javie/ ) to wtedy używam jakiejś implementacji, a nie samego JDBC. Czyli twórcy JEE tak jakby mówią użytkownikom jak mają pisać implementacje, podają zasady ktorych maja się trzymać - właśnie za pomocą interfejsów?
    3.Mówisz, że za Springiem jestes.. ale widze, że JEE jakoś zagorzale nie odmawiasz, więc mam rozumieć, że warto się tego uczyć? I wspomagac jakimiś gadżetami Springowymi typu IoC, DI, Security i co bozia dała?
  2. Wiem, że ty pracujesz jako developer javy :) i skoro jesteś za Springiem to starcza ci to w codziennej pracy i do dalszego rozwoju? Jeśli ja zostałbym "fanem JEE", to również by mi starczyło?

@hcubyc
Co do springa security - mniej-wiecej służy on do tego, żeby wprowadzić autoryzacje do aplikacji? prościej: strona z logowniem - jeden user coś może, inny nie? ;)
Tak też właśnie widze, generalnie w JSF javowe są ManagedBeany które coś-tam robią. Nie ma tu jednak typowo back-endowej logiki która moge dodać używając np EJB (jakiś odpowiednik springa?) mam racje? Często jak widze kod innych, znacznie bardziej zaawansowanych javowców to szczena opada bo używają klas, których ja nawet na oczy nie widziałem mimo, że po częsci nawet są w JDK, chociaż duża ilość jest z innych bibliotek/frameworków

BUZZWORDS: :D

  1. co oznacza out-of-the-box @Shalom
  2. co oznacza "wystawić rest" @hcubyc

Może Od razu podziękuje wam za tyle odpowiedzi wartościowych i odwdzięczę się kciukami w góre :P oby tak dalej

1

@azalut
Co do spring security - tak, ale nie znam go za dobrze, więc możliwe że potrafi jakieś czary, o których nie wiem
Co rozumiesz jako back-endowa logika? Jak dla mnie managed beany to już backend, ale możesz też robić inne rzeczy, typu własny servlet, filtr, przepisywanie urli etc
Co do klas/bibliotek - też możesz ich używać ; ) Ja czasem rezygnuję z jakiejś zewnętrznej biblioteki, która zawiera tylko jedną funkcjonalność, która mnie interesuje - jeśli dam radę to staram się wtedy sam napisać co potrzebuje, nie wiem czy to dobre rozwiązanie, ale przynajmniej ja mogę sobie liznąć jakiś problem.

http://pl.wikipedia.org/wiki/Representational_State_Transfer
Nie bawiłem się w to jeszcze, ale ja to rozumiem tak, że wystawiasz po stronie serwera dane np. w JSONie i potem robisz klienty, np. www czy mobilny - dane przetwarzane są w sumie w ten sam sposób. Jak pieprze głupoty to niech ktoś poprawi

0

Jeśli chodzi o REST, to jest to podejście usługowe. Nie jesteś "związany" z konkretną technologią odpowiedzialną za GUI. Wysyłasz zapytania HTTP jak GET, PUT, POST, DELETE pod konkretny adres, dostajesz lub wysyłasz np. JSON i tyle. Twoje zadanie polega na obróbce tego co dostaniesz.

1

Nie rozczytywałem się w całym wątku ale tylko przekaże podsumowanie moich wrażeń z obu technologii:

Jeżeli po prostu potrzebujesz GUI w przeglądarce: JSF (+ np. PrimeFaces albo jakiś inny zbiór komponentów przygotowanych pod JSF)
Ukryje przed tobą dużo babrania w HTML/CSS/JS/HTTP

Jeżeli potrzebujesz portal z SEO, API w REST i mashapami: Spring MVC
Wtedy HTML/CSS/JS/HTTP weźmiesz za pysk

PS. Mieszać technologie typu JSF+Spring lub Spring MVC + EJB/CDI można... ale nie polecam. Pojawiają się różnego typu niuanse oraz glue code do napisania. JSF tak czy owak wepchnie Cię trochę w CDI, a Spring MVC w samego Spring IoC. Wieć powstanie Ci kobyła, a im więcej libów tym częściej na jakiegoś buga w nich trafisz. (nie piszcie mi że wszystko działa pięknie bo Wam zaraz poprzyklejam linki do mich zgłoszeń na JIRAch :P )

1

@Shalom 1.czyli tak, są dwa frameworki: JSF (MVC) i Spring MVC (oba sa modelami MVC). W JSF frontend zrobie za pomoca Primefaces/Icefaces/Richfaces, natomiast w Spring MVC frontend zrobie tak jak mówisz np: html+jQuery?
Bo rozumiem tak jakbyś mówił ze JSF jest od frontendu, a z tego co mi wiadomo to jest framework MVC - czyli tak jak spring MVC. Dobrze to rozumuje (to dla mnie ważne)?

No ale co to niby jest MVC? Model View Controller. To są wszystko na dobrą sprawę elementy frontu. Model to dane które wyświetlasz, View to sposób w jaki je prezentujesz a Contrller to logika która sprawia że po kliknięciu w dany link wyświetla się to co powinno. Tak działają zwykłe "stronki". Java służy do pisania aplikacji webowych, a te wymagają backendu - czegoś co faktycznie "coś robi". Oczywiście można "Model" nazwać jakimś backendem, ale zwykle dość ubogim. Co innego jak piszesz na przykład Aplikację webową do wyświetlania stanu jakiegoś satelity, wtedy backend to logika odpowiedzialna za przetwarzanie informacji o tym satelicie. Albo jak piszesz system do rezerwacji biletów lotnicznych to backend stanowi cała logika związana z szukaniem i rezerwowaniem biletów.

  1. Czyli jeśli łączę się w prosty sposób z MySQL/SQLite (tj. tutaj: http://javastart.pl/zaawansowa[...]ie/bazy-danych-sqlite-w-javie/ ) to wtedy używam jakiejś implementacji, a nie samego JDBC. Czyli twórcy JEE tak jakby mówią użytkownikom jak mają pisać implementacje, podają zasady ktorych maja się trzymać - właśnie za pomocą interfejsów?

Żartujesz? Masz w tym tutorialu napisane że musisz dodać do projektu jara ze sterownikiem SQLite/MySQL dla JDBC. To jest właśnie ta implementacja. Zauważ że wszystkie importy w kodzie które masz odnoszą sie do klas javowych a nie do tego dodanego jara, a jednak jest on do czegoś potrzebny ;)

3.Mówisz, że za Springiem jestes.. ale widze, że JEE jakoś zagorzale nie odmawiasz, więc mam rozumieć, że warto się tego uczyć? I wspomagac jakimiś gadżetami Springowymi typu IoC, DI, Security i co bozia dała?

Bo tak jak mówiłem - obie technologie są dobre i ciekawe. Szczególnie jeśli chodzi o komponenty JEE które są używane i tu i tu -> JPA, JTA, JAX-RS, JAX-WS, JMS.

  1. Wiem, że ty pracujesz jako developer javy i skoro jesteś za Springiem to starcza ci to w codziennej pracy i do dalszego rozwoju? Jeśli ja zostałbym "fanem JEE", to również by mi starczyło?

Akurat dość niedawno zmieniłem pracę i chwilowo developuje sobie w Pythonie (w sumie z własnego wyboru, lepiej sie nadawał), ale kiedy pracowałem w Javie to akurat przy projektach które korzystały ze Springa. Jak trafisz do firmy/projektu gdzie uzywają JEE to będziesz używał JEE :)

1

Jeśli chcesz pisać w Javie, to i tak będziesz musiał poznać jakiegoś JBoss'a czy Glassfisha, Eclipse, NetBeans'a czy IntellJ IDEA, JPA, JSF, CDI, EJB, Spring(i jego moduły np. AOP, Security), Servlety RESTy. Nie ma raczej sensu pytać czego masz się konkretnie uczyć, bo i tak Twoja ewentualna praca to zweryfikuje. Może być tak, że pójdziesz do pracy jak Java Dev, a będziesz pisać w JavaScriptcie. Ja w tej chwili mam np. zaimplementować warstwę serwisową (rest), logiki(ejb) oraz danych(hibernate) wszystko w Java EE + całe gui jako single app page, w EXT JS. Przy tym jak mam wolną chwilę to jestem w innym projekcie, gdzie mam np. hurtownię danych JSF(primefaces), ejb, dodatkowo SSO (Spring) i parę innych rzeczy. Ogólnie wniosek jest taki, że robisz to co Ci każą, a nie to co lubisz/chcesz ;)

0

@hcubyc
Logika backendowa wg mnie to wszystko co coś liczy, pobiera z bazy, odnajduje pobiera przetwarza, a potem zwraca jako model do wyswietlenia. Tzn - managedBeany na moje oko nie są logika back-endową, ale tylko miejscem gdzie możemy stworzyć ewentualne obiekty tej logikii i dostać jakąś odpowiedź od niej w postaci tych danych do wyświetlenia. Ja to tak rozumiem :)
Co do pisania własnych bibliotek - podejście podobno niedobre, bo po co pisać to co juz jest napisane, ale wg mnie dla własnej edukacji warto, bo zawsze coś tam się dowiemy więcej

@NoZi
Tzn. REST służy do tego, żeby aplikacje napisana "wystawic" na serwerze tak, żeby dało rade napisać do niej aplikacje na androida/ios itd?

@walec51
Powiem Ci, że mój cały ład w głowie został przez twój post zrujnowany :D to znaczy, że JSF to takie podejście "na szybko zrobić ładną stronke" a Spring to bardziej.. kopanie w tunelu?
Rozumiem, że wg ciebie lepiej nie łączyć stosu springa ze stosem JEE bo wyjdzie klapa, a same sobie te technologie wystarczą?

@Shalom
Co do MVC ja go rozumiem tak, że View - to co widzimy, Model - jakies tam dane do wyswietlenia w widoku pobrane z logiki, Controller - element odpowiedzialny za logike, spoiwo miedzy View, a Model. Z tym, że nie w zupełności, że załózmy jedna metoda ma 500 linijek bo pobiera coś z bazy, coś tam wertuje i dopiero oddaje. Może robie źle, ale Controllera jeśli chodzi o JSF w poszczególnych managedBeanach wyobrażam sobie tak, że mam jedną, krótka metode, która z jakiegoś tam wczesniej napisanego kodu do np pobierania z MySQL coś bierze i zwraca do widoku. Czyli controller to element komunikacyjny miedzy widokiem, a logiką
Tutorial o bazie danych zrozumiałem :D tylko chciałem go podać jako przykład do tego co mówiłem, w takim razie ten "sterownik" to implemenacja taka jak np Hibernate - tylko o mega okrojonych możliwościach? :)
Python, tez o nim myślałem swojego czasu, wydaje sie przyjemny nawet z nazwy, ale to tak BTW

@NoZi

Ogólnie wniosek jest taki, że robisz to co Ci każą, a nie to co lubisz/chcesz ;)

To znaczy, że równie dobrze można nie umieć nic bo jesli ogarne JEE a trafie do projektu na Springu to cały misterny plan w pizdu i na nic mi sie to JEE zda? troche szalone
Przykładowo taki szef działu, jakis CEO i tak dalej, w takim razie muszą znać tak na prawde.. wszystko? (idąc ścieżką kariery: był nowy, lepszy, wyrózniał się, ktoś go zauważył awansował, awansował i trafił wysoko). kiedy to w ogóle pojąć? może praca uczy dużo szybciej niz każdy siebie indywidualnie?

@Wibowit
Tak po przespanej nocy, nie wiem skąd, wpadło mi do głowy pytanie: pracujesz jako developer javy i przy takiej ilości technologii javowej masz czas żeby "hobbystycznie" się uczyć kompletnie innych języków i innych narzędzi? no niezle :o To sie wręcz kłóci ze słowami NoZi'ego

Dzieki za odpowiedzi, jestem na prawde wdzięczny

0

@Wibowit
Tak po przespanej nocy, nie wiem skąd, wpadło mi do głowy pytanie: pracujesz jako developer javy i przy takiej ilości technologii javowej masz czas żeby "hobbystycznie" się uczyć kompletnie innych języków i innych narzędzi? no niezle :o To sie wręcz kłóci ze słowami NoZi'ego

Że tak powiem, łączę pracę z nauką :P Np Scali nauczyłem się (wstępnie) nudząc się w Comarchu ;]

0

Z tym, że nie w zupełności, że załózmy jedna metoda ma 500 linijek bo pobiera coś z bazy, coś tam wertuje i dopiero oddaje. Może robie źle

Jak masz metody na 500 linijek to na pewno robisz coś źle ;)

, ale Controllera jeśli chodzi o JSF w poszczególnych managedBeanach wyobrażam sobie tak, że mam jedną, krótka metode, która z jakiegoś tam wczesniej napisanego kodu do np pobierania z MySQL coś bierze i zwraca do widoku. Czyli controller to element komunikacyjny miedzy widokiem, a logiką

Kontroler przekazuje do Modelu żądania użytkownika i odzwierciedla w Widoku zmiany Modelu. W JSFie na dobrą sprawę "kontroler" to jest faces-config i navigation rules a nie Managed Beany. Beany to jest Model. Kontroler mówi tylko "te dane wstaw do tego widoku". Pobranie danych i inne cuda na kiju to powinny być zupełnie inna warstwą - serwisów, na przykład implmentowanych jako EJB.

Tutorial o bazie danych zrozumiałem tylko chciałem go podać jako przykład do tego co mówiłem, w takim razie ten "sterownik" to implemenacja taka jak np Hibernate - tylko o mega okrojonych możliwościach?

Nie. Sterownik JDBC to implementacja JDBC. A Hibernate to implementacja JPA ;] JDBC pozwala ci na wykonywanie zapytań do bazy a JPA pozwala ci na mapowanie obiektów na relacyjną bazę danych i trochę bardziej uniwersalne korzystanie z bazy. Ale nie pisałbym o "okrojonych" możliwościach bo implementacja JPA potrzebuje sterownika JDBC do danej bazy tak czy siak, bo jest zaimplementowana przy użyciu JDBC.

Przykładowo taki szef działu, jakis CEO i tak dalej, w takim razie muszą znać tak na prawde.. wszystko?

Często nie umieją absolutnie nic ;) To wcale nie jest tak że z szarego kodera zostaje się dyrektorem, przykro mi. To są inne ścieżki kariery trochę. Z kodera możesz zostać jakimś architektem na przykład. Czemu tak jest? Bo dobry koder wcale nie będzie dobrym managerem :) W efekcie "awansowanie" jakiegoś senior developera na managera może się skończyć tak że stracisz dobrego kodera, a zyskasz kijowego managera.

0

O to właśnie chodzi, że takich metod na 500 pasków nie mam :D ten początek zdania "Może robie źle[..]" tyczy się juz kolejnej myśli
Od JSF 2.0 (teraz mamy 2.2) w ManagedBeanach za pomoca adnotacji mozemy właściwie manipulować faces-config'iem. Co do nawigacji po stronach - wystarczy zwrócić prosty string z nazwą strony bez sufiksu .xhtml i zostaniemy przeniesieni. Także może jednak to powoli idzie w strone, gdzie ManagedBeany będą controlerem?
Tzn oprócz MVC mamy tez warstwe EJB całkiem odseparowaną od MVC? czy w jakiś sposób połączoną?

Co do JDBC i Hibernate - no racja.. ;) troche logiczne

edit
no dobra, może z tym CEO sie pospieszyłem - ale chodzi mi właśnie o takiego architekta, wysoki stopień kodera. Mam racje?

0

Od JSF 2.0 (teraz mamy 2.2) w ManagedBeanach za pomoca adnotacji mozemy właściwie manipulować faces-config'iem. Co do nawigacji po stronach - wystarczy zwrócić prosty string z nazwą strony bez sufiksu .xhtml i zostaniemy przeniesieni. Także może jednak to powoli idzie w strone, gdzie ManagedBeany będą controlerem?

Tak, w takiej sytuacji managed bean będzie kontrolerem i w sumie będzie to przesunięte w kierunku czegoś na wzór Spring MVC.

Tzn oprócz MVC mamy tez warstwe EJB całkiem odseparowaną od MVC? czy w jakiś sposób połączoną?

No podłączoną - w taki sposób że twój managed bean będzie miał przez CDI wstrzyknięte zależności od tych serwisów EJB.

1
azalut napisał(a):

@walec51
Powiem Ci, że mój cały ład w głowie został przez twój post zrujnowany :D to znaczy, że JSF to takie podejście "na szybko zrobić ładną stronke" a Spring to bardziej.. kopanie w tunelu?
Rozumiem, że wg ciebie lepiej nie łączyć stosu springa ze stosem JEE bo wyjdzie klapa, a same sobie te technologie wystarczą?

Trochę nad interpretujesz moją wypowiedź.

JSF wprowadza bardzo usystemtyzowany sposób robienia GUI i kod Twojej aplikacji będzie dobrze zorganizowany w tej technologii.
Gorzej jednak z kodem wynikowym HTML/JS oraz adresami URL, który JSF + PrimeFaces wygeneruje za Ciebie.
JSF może przed tobą ukryć dużo z HTML/JS/CSS/HTTP co jest zarówno plusem jak i minusem - w zależności od wymagań danego projektu. Oczywiście na siłę można to wszystko skorygować przy pomocy filtrów i cudów typu PrettyFaces ale to bardziej naginanie frameworku niż jego wykorzystywanie.

W Spring MVC organizację HTML/JS/CSS/HTTP ogarniasz całkowicie sam. Wiec masz na tym pełną kontrolę - ale musisz wiedzieć sam co robisz bo tu Cię framework za rączkę nie poprowadzi.
Łatwiej jest robić w tym aplikacje webowe jeżeli wymagania projektowe (audyt SEO, mashupy itp.) wymagają ręcznego dopracowania HTML/JS/CSS/HTTP. Łatwiej też z API RESTowym: w JSF to zawsze oddzielna robota do wykonania (zazwyczaj w JAX-RS), w Spring MVC możesz to ogarnąć (jak dobrze przemyślisz budowę forntu) tymi samymi usługami co będą obsługiwać Twoje formularze.

PS. Java EE to masa specek - ja mówię tylko o mieszaniu technologii do IoC: EJB/CDI z Spring IoC. Rezultat zazwyczaj wygląda jak łódka zespawana z tirem.
JSF (o ilę kojarzę w najnowszej wersji) wymusza stosowanie CDI. Połączenie JSF (i w konsekwencji CDI) z Spring IoC może skutkować niepotrzebnymi problemami.

0

@Shalom
Mam rozumieć, że chcąc połączyć logike EJB z JSF, nierozłączną częścią jest CDI? Jest jakaś zasada kiedy w projektach powinno się użyć EJB, a kiedy czystego kodu javowego? wtedy kiedy poziom trudnosci "obliczeń" względnie wzrasta? :)

@walec51
Czyli JSF można nazwać takim "opakowanym Springiem"? Z tego co mi wiadomo Primefaces jest stworzone w jQuery, z resztą gołym okiem widać po efekach typu explode. To by faktycznie miało sens, nie licząc się z tym jak wyglada nasz html/js itd. JSF jest lepszym wyborem bo ma komponenty. W springu wchodzimy jakby troche głębiej

W zwiazku z tym domyślam się, że więcej materiału do ogarnięcia byłoby w Springu, bo dochodzi jeszcze pare innych jezyków webowych tj. html5 css3 czy jakis jQuery, DOJO? Nawet nie webowy developer, myśle, że ich podstawy zna (moze za wyjatkiem java scriptu), ale żeby stworzyć coś na poziom Primefaces trzeba jednak troche wysiłku

co do P.S:
ahh troche źle zrozumiałem. Myślałem, że chodzi o mieszanie dowolnego elementu stosu tj. JSF + Spring security.

JSF (o ilę kojarzę w najnowszej wersji) wymusza stosowanie CDI.

Nie wiem czy będziesz w stanie mi to powiedzieć, ale może wiesz w którym miejscu to ma miejsce? :P

0

Od wersji JSF 2.2 ma twardą zależność do CDI co znacznie ułatwiło devom integrację. W kolejnych wersjach prawdopodobnie CDI stanie się integralną częścią JSF.
Generalnie standardowe Java EE posuwa się w ciekawym kierunku ale na razie jest spory syf co do IoC. EJB ma swój model, JSF ma swój model, CDI ma swój model. Te wszystkie trzy w kolejnych edycjach EE ujednolicają i integrują ale ciężko to dosyć ogarnąć.

EJB to technologia która (poza własnym IoC) zapewnia Ci deklaratywne zarządzanie transakcjami. Spring (również po za IoC) to zapewnia. Przewagą EJB nad Springiem jest to że out-of-the-box wspiera transakcje rozproszone między systemami. Ale raczej nie siedzisz w tej skali projektach żeby to było dla Ciebie killer ficzerem.

Czyli JSF można nazwać takim "opakowanym Springiem"?

Chodzi ci o Spring MVC ? - mów konkretnie na przyszłość bo pod szyldem Spring jest masa lib'ów.

Nie. To dwa zupełnie różne podejścia do tematu.

PS. PrimeFaces to de facto opakowane JSF - bo czyste JSF według spec (na którym bazuje PrimeFaces) nie daje Ci żadnych gotowych komponentów.

PSS. Spring Security wymusza stosowanie Spring IoC, tak samo jak Spring MVC.

0

Mam rozumieć, że chcąc połączyć logike EJB z JSF, nierozłączną częścią jest CDI?

Nie, przynajmniej nie w poprzednich wersjach bo można stosować adnotacje @EJB.

Jest jakaś zasada kiedy w projektach powinno się użyć EJB, a kiedy czystego kodu javowego? wtedy kiedy poziom trudnosci "obliczeń" względnie wzrasta?

Co to niby znaczy "czystego kodu javowego"? Przecież GDZIEŚ ten kod musisz mieć i potem jakoś obiekty z tym kodem musisz udostępnić kontrolerowi. W Springu taki kod byłby w @Service, @Component czy @Repository a w JEE taki kod będzie w EJB właśnie. No bo gdzie byś ten kod chciał dać, nie gwałcąc przy tym zasady jednej odpowiedzialności?

0

@walec51
Tak myślałem, żeby dopisać to MVC jak pisalem "opakowanym Springiem" :) ale tak, o to mi chodziło. Co do projektów - fakt, do takich kolosów jeszcze daleeeka droga.

PS. PrimeFaces to de facto opakowane JSF - bo czyste JSF według spec (na którym bazuje PrimeFaces) nie daje Ci żadnych gotowych komponentów.

Tak, racja. JSF to tylko specyfikacja, a Facelets to ta "domyślna" implementacja?

PSS. Spring Security wymusza stosowanie Spring IoC, tak samo jak Spring MVC.

Wszystko co Springowe chyba działa na tym IoC ;)? Inaczej mówiąc jak Spring Security to nie EJB/CDI? Wtedy prędzej sie brać za połączenie Spring Ioc/DI + Spring Security + JSF?

@Shalom
Może troszke źle się wyraziłem. Chodziło o to, kiedy użyc EJB, a kiedy go nie użyć :) Pisząc jakies easy apps, tak jak teraz pisze, sprawdzając po prostu jak co działa, raczej tego EJB nie użyje. Jak bede pisał większy projekt to pewnie EJB stanowi jakieś ułatwienie. W pytaniu chodzi o to kiedy jest ta granica, że warto użyc, a kiedy nie
Co do transakcji, wiem, że to zestaw metod do operacji na danych, przynajmniej tak mi sie wydaje. Jak byście opisali co to transakcja w 1-2 zdaniach?

1

Transakcja to jest atomowa operacja która albo wykona się cała albo wcale. Wyobraź sobie że robisz system do przelewów bankowych. Klient robi przelew wewnętrzny więc:

  • trzeba zabrać z konta klienta
  • trzeba dać na konto na które przelał
    Wyobraź sobie teraz że w "międzyczasie" coś się posypało (co wcale takie nieprawdopodobne nie jest, bo system bankowy może działać na wielu współpracujących serwerach jednocześnie). Chciałbyś w takiej sytuacji wycofać wszystkie operacje, zeby uniknąć sytuacji że ściągnąłeś klientowi kasę ale nie puściłeś dalej. W związku z tym taka operacja będzie objęta transakcją. Jak się wysypie w trakcie działania to wycofane zostaną wszystkie operacje.
2

Jako że wątek się niemiłosiernie przeciąga: DOSYĆ GADANIA ! SKODŹ SOBIE PROTOTYP !

Próbujesz sobie skombinować "idealny" stos, a nawet nie wiesz co to są transakcje. Zamiast dywagować skodź sobie jakieś dwie prototypowe aplikacje. Jedną w JSF/CDI/EJB/JPA, drugą w Spring MVC/IoC/Transactions/JPA. Pod takowe kombinacje masz masę tutoriali - tylko bierz jakieś nowsze żebyś w Springu XMLem się nie udusił.

Poza tym poznaj jak działają relacyjne bazy danych oraz ACID.

0

@walec51
Czytasz mi w myślach :) własnie mialem pytać czy to dobry pomysł zeby napisac cos w jednym, potem drugim, a na koniec ewentualnie zmieszać. Troche to czasu zajmie.. ale ile sie dowiem! to chyba najlepszy sposób zeby odkryć różnice, zalety i wady - samemu spróbować. Nie chce kombinować idealnego stosu tylko myśle czym moge wesprzeć moja aplikacje która napisze w JSF + Primefaces, żeby sie coś dowiedzieć, coś nauczyć i dowiedzieć czy warto JSF czy Spring.
Bardzo dużo wątpliwości moich rozwialiście, jak was kiedys spotkam stawiam piwo ;)
W każdym razie - dzieki za pomocne odp!

0

Co do Spring Security i JSF, jestem zadowolonym użytkownikiem tej integracji, z użyciem JSF 2.2 (niestety, ze wzgledu na legacy beans nie mam np. dostepu do @FlowScoped, ale moge uzyc Spring Webglow), ale legacy Managed Bean (nie CDI) i Spring jako IoC. Reszta logiki biznesowej siedzi w EJB. Dziala bardzo przyjemnie jak juz sie ogarnie konfiguracje. Nie znam sensownej alternatywy dla Spring Security, JASS jest dla mnie zbyt prymitywny, a Apache Shiro toporne w uzyciu i nie zawsze chce dzialac tak jak opisuja w dokumentacji. W razie czego polecam.

1 użytkowników online, w tym zalogowanych: 0, gości: 1