Jaki framework wybrać-Seam, Wicket, JSF czy GWT? [zamknięte]

Używam GWT od wersji 1.4 i JSF od czasu pojawienia się specyfikacji 2.0.

GWT jest frameworkiem po stronie klienta, generuje JavaScript z Javy. Twoja Architektura byłaby czystym klientem-serwerem, co oznacza:

• najlepiej korzystać z usług gruboziarnistych
• Wszystkie obiekty po stronie klienta powinny być w pełni serializowalne (oznacza to, że nie ma leniwego obciążenia lub wzorca OpenSessionInView)
• od GWT 2.0 można zaprojektować gui za pomocą xhtml, co jest znacznie łatwiejsze w w tym celu prosimy o zapoznanie się z naszą Polityką Prywatności.]}
• GWT ma tendencję do faworyzowania dobrej architektury, jeśli ją zepsujesz, będzie to złe do refaktor
• Perfect Historia (przycisk Wstecz przeglądarki, bookmarkable URL) wsparcie jest trudne , prawdopodobnie trzeba rzucić własną, chociaż łatwo jest włamać coś z przodu

JSF jest frameworkiem opartym na komponentach, z projektem typu view-first (code-behind, jeśli chcesz):

• łatwiej jest zrobić jakiś rodzaj webapps (stateful, like shopping cart)
• JSF + Seam ma wsparcie dla rozmów (myśl Strony podobne do kreatora, które utrzymują stan na kilku stronach)
• ty Możesz zaimplementować OpenSessionInView, w zależności od stosu. Prawdopodobnie nie jest to zalecane, jeśli używasz EJB dla warstwy usług / biznesu
• JSF2 ma superb Wsparcie dla AJAX, a z pakietu komponentów takich jak RichFaces można zbudować ładne webapps
  • ale jeśli chcesz wykwintne zachowanie javascript, będziesz musiał napisać trochę javascript
• JSF śledzi bieżący stan interfejsu użytkownika po stronie klienta lub serwera. Jest to kompromis między ruchem sieciowym a pamięcią serwerową.

Wznowienie:

• GWT jest bardziej odpowiedni dla aplikacji internetowych (pomyśl gmail), które wymagają najlepszej wydajności po stronie klienta. Łatwo jest pisać własne komponenty (piszesz Javę), a ponieważ strona serwera jest tylko warstwą usług, możesz być w pełni bezpaństwowy na serwerze bok.
• JSF jest bardziej odpowiedni dla głównie aplikacji CRUD, które lepiej nadają się do rzeczy zorientowanych na komponenty: pomyśl o systemie rezerwacji hoteli/lotów, sklepie internetowym z koszykiem itp

Dzięki, że jesteście trzeźwi i trzymacie się tej dyskusji. Jestem użytkownikiem wicket i uwielbiam to. Moje główne powody to:

1. to struktura składowa. Uwielbiam pracować z komponentami w przeciwieństwie do pełnych stron.

2. Mogę pozwolić projektantom pracować nad szablonami i stronami, tak jak ja pracuję nad częściami Javy

3. Nie ma nic nowego do nauczenia. Its "just java and just HTML"

Podoba mi się jego mechanizm awaryjny ajax. Gdzie nie ma javascript wsparcie w przeglądarce, zwłaszcza na urządzeniach mobilnych, wraca do zwykłego html i wszystko działa.
4. jego brak konfiguracji xml to plus
5. obsługuje wszystko, czego chciałbym w aplikacji internetowej. np. Walidacja, Internacjonalizacja, obsługa przycisków Wstecz i restful URLs między innymi

Moje poprzednie doświadczenie to GWT i JSF 1.0

Seam jest frameworkiem aplikacji, a nie warstwą prezentacji. Został on pierwotnie opracowany, aby uczynić JSF mniej bolesnym, ale przekształcił się w bardziej ogólny framework dependency injection.

Wierzę, że można użyć Seam z JSF, Wicket i GWT. Obsługa JSF jest podstawowa i doskonała; nie jestem pewien, jak dobrze wspierane są pozostałe dwa.

Ponieważ głównym celem Twoich kryteriów wydaje się być rynkowość Twoich umiejętności, sugerowałbym wypróbowanie Seam i JSF poprzez Facelets. JSF jest dobrze przyjętym standardem i jest naprawdę przyjemny w użyciu, jeśli używasz Facelets. Możesz mieć funkcjonalność Ajax za pomocą Richfaces i Ajax4jsf. Seam jest mniej więcej standaryzowany za pośrednictwem JCP.

Moje doświadczenie jest w porządku chronologicznym:

Raw servlets - (tak, dużo ciężkiej pracy, ale to były wczesne dni i byliśmy chętni bobry!)

JSP-myślałem, że to beez neez w momencie, gdy wyszedł (gdybyśmy tylko wiedzieli ;))

Echo-Awesome framework, ale nie dla stron, które muszą być przyjazne dla wyszukiwarek (same problem z GWT)

Wicket-Awesome framework - Programiści w pełni rozumieją pojęcie OO (W przeciwieństwie do JSP i wielu innych) i mają zastosowałem do tego frameworka wszystkie zwykłe oo. Jeśli cenisz sobie "reusability", jeśli doceniasz enkapsulację, jeśli doceniasz separację problemów i jeśli lubisz wiązać swój model z kodem interfejsu użytkownika bez martwienia się o rozlokowanie obiektów i inne tego typu brzydoty, to jest to framework dla Ciebie!

W długoterminowym scenariuszu polecam użycie technologii popartych specyfikacją Sun. Do tej pory udowodniono, że daje to wiele implementacji, co skutkuje wyborem (często również implementacjami open source), a także bardzo dobrze zdefiniowanym zachowaniem.

To pomoże Ci w scenariuszu konserwacji, który - miejmy nadzieję-Twój kod skończy się zbyt na czas. Dobrze napisany kod żyje wiecznie:)

W tym konkretnym scenariuszu sugerowałbym JSF. Próbowałem tylko Implementacja Apache 1.1, ale bolało być na szczycie JSP. Mamy go wkrótce zrewidować-spodziewam się, że zajrzę do JSF na facetach.

Używałem Wicket i GWT dość mocno. Nigdy nie nauczyłam się kochać Wicketa.

Moje ego blogowało o tym http://salk31.blogspot.com/2009/07/wicket-ajax.html

Patrząc dzisiaj na GWT 2.0 uiBinder przypomniało mi, jak irytujące było w Wicket dopasowanie drzewa komponentów XML do tego stworzonego w Javie. Jak dla mnie GWT wygląda zdecydowanie lepiej.

Nie używałem Wicket od ponad roku więc może naprawili dużo tego ale biorąc pod uwagę nowoczesne przeglądarka i obsługa JS nie widzę sensu robienia tego wszystkiego na serwerze(wiem, Znam lokalizację danych).

Jeśli rozważasz tylko rynek pracy, powinieneś wybrać JSF. Ale wierzę, że przyszłość RIA należy do GWT i gwt, takich jak technologie po stronie klienta.

Myślę, że najbardziej oczywistym plusem GWT jest to, że jest on lepiej skalowalny niż technologie warstwy prezentacyjnej po stronie serwera, takie jak JSF, wicket. Ponieważ serwer nie musi przechowywać stanu klienta i używana jest również moc procesora klienta.. Jest to ogromna zaleta, nie musisz serializować stanu klienta między komputerami serwera, aby system odporny na uszkodzenia achive.

Wiem, że jest trochę późno, ale jest już dużo porównania na Framewrok, espcially ten, który miał miejsce podczas durinf Devox 2010 conf:

Http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM + Web + Framework

To powinno pomóc w wyborze:)

Zacząłem od JSF (1.1 i 1.2) i było to tak bolesne, że zdecydowałem się na zmiany w kolejnych projektach. Trochę poszperałem i postanowiłem spróbować. to była przyjemność. Próbowałem również JSF 2, ale nadal jest to to samo.

Oba są frameworkami komponentowymi, ale z Wicket jest łatwo, podczas gdy z JSF jest kompletny bałagan.

Bramka nad JSF:

• w HTML są HTML. JSF ma własne znaczniki znaczników. H: dataTable (dla tabel) jest nonsensem. Believe ja, Inżynierowie Sun musieli być pijani, kiedy to projektowali.
• w takich sprawach jak bezpieczeństwo,
• w JSF pasek nawigacji pokazuje poprzedni URL. Naprawdę dziwne.
• JSF wydaje mi się bardzo ciężki, a z bibliotekami takimi jak Rich czy Prime jeszcze bardziej.
• czasami wydaje się niemożliwe, aby wiedzieć, co się dzieje. Zawsze kończysz krzycząc na swój komputer, bo nie wiesz, dlaczego robi JSF.

JSF over Wicket:

• W Wicket napiszesz więcej Java (powiązanie z HTML). Przynajmniej Twoje IDE zapewni wsparcie refaktoryzacji i walidacji.
Zarządzanie zasobami w Wicket jest trochę trudne.
• istnieje znacznie więcej dokumentacji i wsparcia dla JSF

Jedną z powszechnych wad jest to, że rozmiar sesji jest problemem (ponieważ komponenty graficzne są tam przechowywane).

Podsumowując, jeśli musisz decydować tylko między Wicket a JSF, nie ma dla mnie wątpliwości, Wicket .

JSF jest przestarzały (JSF nie jest nawet wymieniony jako framework do porównania, gdy ewangeliści porównują lub mówią o frameworkach internetowych w 2010 roku).

Teraz pełne aplikacje wielkoskalowe są tworzone przy użyciu GWT, YUI, JQuery itp.

Przeczytanie niektórych artykułów w google i wyżej będzie oczywiste.

(wszystkie zadania w JSF mają obsługiwać starsze aplikacje).