Jakie są wady i zalety różnych platform internetowych Java? [Zamknięte]


85

Rozważam stworzenie własnej strony internetowej w Javie i próbuję zdecydować, jakiego frameworka użyć. Jednak szybkie wyszukiwanie struktur Java zwraca ponad 50 do wyboru!

Moja strona internetowa będzie służyła mojej własnej przyjemności z budowania jej na początku, ale jeśli stanie się popularna, dobrze byłoby, gdyby miała pewną skalowalność lub przynajmniej móc ją przeprojektować.

Jakie są główne różnice między bardziej popularnymi frameworkami? Czy są sytuacje, w których jeden znacznie przewyższa inne? Na przykład aplikacje korporacyjne o dużym natężeniu ruchu w porównaniu z małymi aplikacjami o małym ruchu. Zastanawiam się również, czy niektóre są znacznie łatwiejsze do nauczenia się i używania niż inne.

Czy jest ktoś, kto ma doświadczenie z niektórymi z tych frameworków i może udzielić rekomendacji? Czy sama liczba wyborów służy jedynie jako wczesne ostrzeżenie, aby w miarę możliwości unikać tworzenia stron internetowych w języku Java?


Do pewnego stopnia to tak, jakby powiedzieć „szybkie wyszukiwanie narzędzi zwraca więcej niż 50 do wyboru; czy powinienem wybrać młotek, śrubokręt czy szczypce?” Jednak w przypadku pytań podrzędnych jest to przyzwoite pytanie „dobre subiektywne”.
Wyskakuje

"Zabawne" jak zwykle, niezwykle przydatne pytanie i odpowiedzi (właśnie zamówiłem książkę o Wickecie, dziękuję wszystkim), ale cały post jest zamknięty jako mało konstruktywny. "to pytanie PRAWDOPODOBNIE" - i ten suchy fakt, nic spekulatywnego, o ironio ...
greenoldman

Odpowiedzi:


59

Dość często używałem Tapestry 3 , Wicket , Echo i JSF . Naprawdę radziłbym przejrzeć je i wybrać ten, który wydaje się najłatwiejszy i najlepiej pasuje do sposobu, w jaki wolisz pracować.

Spośród nich najwygodniejszy dla mnie był Wicket , ze względu na lekki charakter budowania komponentów i prostotę tworzenia szablonów stron. Działa to podwójnie, więc jeśli używasz własnego kodu db zamiast Hibernate lub innego frameworka (nigdy nie byłem całkowicie zadowolony z Wicket Hibernate lub Spring Integration).

Echo jest świetne, jeśli nie masz nic przeciwko pisaniu całego układu w Javie. Wiem, że teraz jest inaczej, ale nadal uważam, że produkt służy dość wąskiej niszy. Wygląda na to, że zmieniają model rozwoju z każdą główną wersją.

Gobelin to świetny produkt, ale oczywiście bardzo różni się od innych pod względem modelu rozwoju, ponieważ prowadzi go głównie jeden gość. Howard Lewis Ship jest bez wątpienia całkiem sprytny, ale jestem rozczarowany ich decyzją o zapomnieniu wstecznej kompatybilności z każdym wydaniem. Znowu jednak, dla twoich potrzeb może to nie mieć znaczenia i zawsze uważałem, że praca z produktami Tapestry jest przyjemna.

JSF istnieje od lat i nadal wydaje się być czymś, co człowiek ze Struts zbudował, aby rozwiązać wszystkie problemy Struts. Bez zrozumienia wszystkich problemów z Struts. Nadal ma niedokończony wygląd, chociaż produkt jest oczywiście bardzo elastyczny. Używam go i mam do niego sentyment, z wielką nadzieją na przyszłość. Myślę, że następne wydanie (2.0), które ma być dostarczone w JEE6, naprawdę wprowadzi je w swoje własne, z nową składnią szablonów (podobną do Facelets) i uproszczonym modelem komponentów (niestandardowe komponenty tylko w 1 pliku ... wreszcie).

I oczywiście istnieje milion mniejszych frameworków i narzędzi, które zyskują własne poparcie ( Velocity dla podstawowych potrzeb, surowe strony JSP , Struts itp.). Generalnie wolę jednak frameworki zorientowane na komponenty.

Na koniec poleciłbym po prostu przyjrzeć się Tapestry, Wicket i JSF i wybrać ten, który najbardziej Ci odpowiada. Prawdopodobnie znajdziesz taki, który po prostu pasuje do sposobu, w jaki lubisz bardzo szybko pracować.


Jeśli Twoja aplikacja internetowa jest oparta na treści, podobnie jak system forum, zasugeruję użycie GWT i Ext-js. Jeśli Twoja aplikacja internetowa bardziej przypomina aplikację biurkową, taką jak terminal ERP, zasugeruję użycie ZK, Echo3, Vaddin i GWT. Nie proponuję żadnego rozwiązania JSF, ponieważ bez faktu, że jest to standard JEE, nie znalazłem korzyści z ich używania.
Zanyking

1
@Zanyking - Jeśli twoje forum wymaga pozycjonowania, GWT będzie trudne, imo.
jsight

3
JSF jest prawdopodobnie przesadą jak na stronę internetową, zamiast tego
wybrałbym

1
Tapestry, Wicket, JSF i Echo są zorientowane na komponenty, a GWT, Ext-js i Vaadin są zorientowane na Javascript. Nie zapomnij przyjrzeć się wszystkim wspaniałym „klasycznym” frameworkom MVC, takim jak Spring MVC, framework Play, Grails i Stripes. Mają zupełnie inny model programowania niż poprzednie, ale mają inne słodkie punkty (dlatego jest tak wiele frameworków - różne cele, potrzeby i upodobania wymagają różnych narzędzi).
DaGGeRRz

39

Moim ulubionym jest Spring Framework. Z 2.5 Spring MVC jest super, z nowymi adnotacjami, konwencją nad funkcjami konfiguracyjnymi itp.

Jeśli robisz coś bardzo prostego, możesz po prostu spróbować użyć zwykłego Servlet API i nie zawracać sobie głowy frameworkiem.


1
Głosuj za wspominaniem o używaniu zwykłego Servlet API do czegoś prostego.
lsiu

1
Unikałbym wszelkich ram „web mvc” z powodów przedstawionych w (darmowym) pierwszym rozdziale Wicket In Action. Unikałbym również bezpośredniego korzystania z Servlet API, chyba że masz aplikację jednostronicową lub chcesz napisać własny framework od podstaw.
Eelco

3
Spring też mi się podoba, ale stwierdziłem, że cała konfiguracja opłaca się tylko wtedy, gdy piszesz aplikację mahoosive.
Leonard Ehrenfried

1
Nie ma prawie żadnej konfiguracji przy użyciu adnotacji.
bpapa

1
@bpapa Adnotacje jedynie umieszczają konfigurację w twoich klasach java zamiast XML.
Steven

25

Polecam ramę Wicket zorientowaną na komponenty . Pozwala na pisanie aplikacji internetowych w zwykłym, starym kodzie Java, możesz używać POJO jako modelu dla wszystkich komponentów i nie musisz bawić się ogromnymi plikami konfiguracyjnymi XML.

Z powodzeniem stworzyłem aplikację bankowości internetowej w Struts, kiedy odkryłem Wicket i zobaczyłem, jak łatwe może być tworzenie aplikacji internetowych!


17

Niedawno zacząłem używać Stripes Framework . Jeśli szukasz platformy opartej na żądaniach, która jest naprawdę łatwa w użyciu, ale nie nakłada żadnych ograniczeń na to, co robisz, gorąco ją polecam.

Jest podobny do rozpórki, ale wykracza poza to. Istnieją nawet projekty wtyczek, które umożliwiają używanie hibernacji lub jpa przy bardzo małej konfiguracji.

Istnieje wiele dobrych frameworków, chociaż słyszałem, że furtka jest również dobra, ale nie używałem jej.


16

Sam tego nie próbowałem, ale myślę

http://www.playframework.org/

ma duży potencjał ...

pochodzi z php i klasycznego asp, jest to pierwszy framework sieciowy java, który brzmi obiecująco ...


2
To zabawne, że po raz piąty zobaczyłem „Nie używałem tego, ale polecam Play” na stackoverflow.
Marko

11

AKTUALIZACJA: Tapestry 5.2 jest już niedostępny, więc nie jest porzucony, jak się wcześniej wydawało. Moje doświadczenie dotyczy Tapestry 4, a nie 5, więc Twój przebieg może się różnić. Moja opinia o Tapestry zmieniła się na przestrzeni lat; Zmodyfikowałem ten post, aby to odzwierciedlić.

Nie mogę już polecać Tapestry, tak jak wcześniej. Tapestry 5 wydaje się być znaczącym ulepszeniem, ale mój główny problem z Tapestry nie dotyczy samej platformy; jest z ludźmi, którzy za tym stoją.

Historycznie rzecz biorąc, każda większa aktualizacja Tapestry łamała wsteczną kompatybilność ze skrajnymi uprzedzeniami, znacznie bardziej niż można by się spodziewać. Wydaje się, że jest to spowodowane włączeniem nowych technik lub technologii kodowania, które wymagają znacznych przeróbek.

Howard Lewis Ship (główny autor Tapestry) jest z pewnością genialnym deweloperem, ale nie mogę powiedzieć, że zależy mi na jego zarządzaniu projektem Tapestry. Rozwój Tapestry 5 rozpoczął się niemal natychmiast po wysłaniu Tapestry 4. Z tego, co wiem, Ship poświęcił się temu, pozostawiając Tapestry 4 w rękach innych autorów, którzy moim zdaniem nie są tak zdolni jak Ship. Po bolesnym przejściu z Tapestry 3 na Tapestry 4 poczułem, że prawie natychmiast zostałem porzucony.

Oczywiście, wraz z wydaniem Tapestry 5, Tapestry 4 stał się starszym produktem. Nie miałbym z tym problemu, gdyby ścieżka aktualizacji nie była znowu tak brutalna . Więc teraz nasz zespół programistów jest w raczej nie do pozazdroszczenia sytuacji: moglibyśmy nadal korzystać z zasadniczo porzuconej platformy internetowej (Tapestry 4), dokonać ohydnej aktualizacji do Tapestry 5 lub całkowicie zrezygnować z Tapestry i przepisać naszą aplikację przy użyciu innej platformy. Żadna z tych opcji nie jest zbyt atrakcyjna.

Tapestry 5 jest podobno napisany tak, aby zmniejszyć prawdopodobieństwo zerwania aktualizacji od tego momentu. Dobrym przykładem są klasy stron: w poprzednich wcieleniach klasy stron wywodziły się z klasy bazowej dostarczonej przez Tapestry; niezgodne zmiany API w tej klasie były przyczyną dużej liczby problemów ze zgodnością wsteczną. W Tapestry 5 strony są POJO, które w czasie wykonywania są ulepszane za pomocą „magicznego czarodziejskiego pyłu Tapestry” poprzez adnotacje. Tak długo, jak zachowana jest umowa dotycząca adnotacji, zmiany w Tapestry nie wpłyną na klasy stron.

Jeśli tak jest, to napisanie nowej aplikacji przy użyciu Tapestry 5 może się dobrze zakończyć. Ale osobiście nie mam ochoty ponownie położyć ręki na palniku.


Aktualizacja: W miarę upływu czasu wydaje się, że projekt Tapestry został porzucony. Nie było żadnych wydań Tapestry 5 od kwietnia '09, a Tapestry 4, wciąż z kilkoma wybitnymi błędami w JIRA, nie doczekał się aktualizacji od '08. Z tego powodu nie mogę już polecać Tapestry jako realnego wyboru dla frameworka aplikacji internetowych.
Robert J. Walker

Gobelin nie został porzucony. Gałąź Tapestry 5 jest dość aktywna z wersją stabilną 5.1 i 5.2 wkrótce.
Timo Westkämper

Masz rację. W rzeczywistości Tapestry 5.2 został wydany. Zaktualizowałem post, aby odzwierciedlić moją zaktualizowaną opinię o Tapestry.
Robert J. Walker

9

Disclamer: Pracuję w Vaadin (wcześniej IT Mill)

Jeśli robisz coś RIAish, możesz przyjrzeć się Vaadinowi . Jest to framework AJAX zorientowany na interfejs użytkownika typu open source, który według mnie jest przyjemny w użyciu (sam pochodzę z tła PHP).

Istnieje studium przypadku, które porównuje wykonanie tej samej aplikacji (tj. Dwóch aplikacji z tym samym zestawem funkcji) w Icefaces i Vaadin. W skrócie stwierdza, że ​​rozwój interfejsu użytkownika był znacznie szybszy.

Mimo że badanie znajduje się na firmowej wiki, mogę zapewnić, że jest obiektywne, autentyczne i zgodne z prawdą, chociaż nie mogę cię zmusić do wiary.


+1 Framework zostaje przemianowany na vaadin (wcześniej ITMill). Muszę powiedzieć, że vaadin jest bardzo ładnie wyglądającym frameworkiem internetowym i nic poza tym java. Uważam, że to bardzo produktywne.
fmucar

7

Po dłuższej chwili testowania różnych rozwiązań okazało się, że to:

  • Spring MVC dla warstwy prezentacji i kontrolera (brak Spring Webflow, ponieważ moje przepływy są oparte na Ajax)

  • jQuery dla wszystkich rzeczy po stronie klienta

  • Spring Security w aspekcie bezpieczeństwa

  • Hibernacja / JPA2

  • Molo ze względu na kontynuację (kometa)

Miesiąc niezwykle stromej nauki, ale teraz jestem szczęśliwy.

Chciałbym również wspomnieć, że byłem tylko o krok od pominięcia całej tej Javy i nauczenia się Scala / LIFT. Jeśli o mnie chodzi, wszystko w Javie, co jest związane z najnowocześniejszym tworzeniem stron internetowych (kometa, komunikacja asynchroniczna, bezpieczeństwo (tak, nawet z Spring Security!)) Nadal jest trochę hackem (udowodnij mi, że się mylę, proszę !). Dla mnie Scala / LIFT wydaje się być rozwiązaniem bardziej gotowym do użycia i kompleksowym.

Powodem, dla którego w końcu zdecydowałem się nie iść ze Scalą, jest

  • Jako lider projektu muszę wziąć pod uwagę zasoby ludzkie, a programistów Java jest znacznie łatwiejszych niż programistów Scala

  • dla większości programistów w moim zespole funkcjonalna koncepcja Scali, choć jest doskonała, jest trudna do zrozumienia

Pozdrawiam Er


To wszystko jest dobre. Dobry wybór sprężyny MVC, pozostań po bezpiecznej (i mądrej) stronie.
Victor Ionescu,

5

Słyszałem też dobre rzeczy o Spring Framework. Ogólnie rzecz biorąc, byłem rozczarowany większością przeglądanych przeze mnie frameworków Java (szczególnie Struts).

W przypadku prostej aplikacji zdecydowanie rozważyłbym użycie „surowych” serwletów i stron JSP i nie martwiłbym się o przyjęcie struktury. Jeśli serwlety są dobrze napisane, w przyszłości powinno być łatwo przenieść do frameworka, jeśli będzie to konieczne, gdy aplikacja stanie się bardziej złożona.


1
+1 za „Jeśli serwlety są dobrze napisane ...”
Chris


4

Wszyscy - w tym problem ;-)


3

Myślę, że dla twoich skromnych wymagań wystarczy zakodować serwlety lub proste strony jsp, które możesz obsługiwać z serwera Tomcat. Nie sądzę, abyś potrzebował żadnego rodzaju struktury internetowej (takiej jak rozpórki) do osobistych danych witryn internetowych


3

Powiedzenie „użyj JSF” jest zbyt proste. Decydując się na użycie JSF, musisz wybrać bibliotekę komponentów. Czy użyjesz MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )? A może ICEfaces ( http://www.icefaces.org/ )? Aha, a jeśli użyjesz ICEfaces, czy użyjesz stron JSP lub Facelets do swoich widoków?

Moim zdaniem trudno powiedzieć. Nikt nie ma czasu, aby ocenić wszystkie obiecujące alternatywy, przynajmniej w projektach, nad którymi pracuję, ponieważ nie są one wystarczająco duże, aby przeprowadzić trzymiesięczne fazy oceny. Jednak powinieneś rozejrzeć się za niektórymi, którzy mają dużą i aktywną społeczność i nie znikną w ciągu roku. JSF istnieje od jakiegoś czasu, a ponieważ jest popychany przez słońce, będzie w pobliżu jeszcze przez jakiś czas. Nie mogę powiedzieć, czy to najlepszy wybór, ale będzie to dobry wybór.


Jsp było dla mnie uciążliwe podczas tworzenia sprzedawanej przez nas aplikacji internetowej. Aktualizacja uwzględni zamiast tego aspekty.
Thorbjørn Ravn Andersen

Tak, do tego czasu jestem już prawie pewien: użyj faceletów zamiast JSP. Jest dużo lepiej i nie widzę żadnych (dużych) wad.
Tim Büthe,


3

W przypadku witryn o dużym natężeniu ruchu użyłbym struktury, która nie zarządza stanem klienta na serwerze - Wicket, JSF i Tapestry zarządzają stanem klienta na serwerze. Używałbym tylko tych frameworków (Wicket jest moim ulubionym), jeśli aplikacja powinna bardziej przypominać aplikację komputerową. Ale spróbuję użyć bardziej skalowalnego i prostszego podejścia REST + AJAX.

Spring MVC byłby kandydatem, ale od Spring MVC 3 ma dziwny model programowania przeciążony adnotacjami, który nie wykorzystuje zalet statycznego pisania. Istnieje wiele innych brzydkich rzeczy, takich jak parametry wyjściowe w metodach w połączeniu ze zwykłym zwrotem, więc są dwa kanały wyjściowe jednej metody. Spring MVC ma również tendencję do ponownego odkrywania koła, dzięki czemu będziesz mieć więcej do skonfigurowania w porównaniu z innymi frameworkami. Naprawdę nie mogę polecić Spring MVC, chociaż ma kilka fajnych pomysłów.

Grails to wygodny sposób na użycie Spring MVC i innych uznanych frameworków, takich jak Hibernate. Kodowanie jest fajne i szybko zobaczysz wyniki.

I nie zapominaj, że Servlet API z kilkoma małymi pomocnikami, takimi jak FreeMarker do tworzenia szablonów, jest bardzo potężny.



2

Moim wyborem byłby Wicket (dla dużych projektów i przewidywalnej bazy użytkowników), GWT (dla dużych projektów, które są głównie dostępne publicznie) lub po prostu framework usług (jak Jersey / JAXRS) wraz z zestawem narzędzi JavaScript (dla małych i średnich projektów) .


2

Polecam Seam, zwłaszcza jeśli potrzebujesz wytrwałości.



1

Aby uzyskać szybkie i wyszukane GUI, możesz użyć JSF z biblioteką Richfaces . Komponenty interfejsu użytkownika Richfaces to łatwe w użyciu i przydatne odniesienia dostępne wraz z demonstracją kodu w witrynie demonstracyjnej. Prawdopodobnie później, gdy Twoja witryna będzie miała więcej danych do obsłużenia i wiele informacji będzie musiało zostać przetworzonych w bazie danych, możesz podłączyć do niej dowolną strukturę dostępu do bazy danych (ORM).


0

Nie mogę uwierzyć, że nikt nie wspomniał o GWT


Naprawdę nie uważałbym GWT za framework aplikacji internetowych (bardziej przypomina zestaw narzędzi internetowych, stąd nazwa). GWT jest jednak świetny i dobrze pasuje na przykład do Springa.
stian

framework lub zestaw narzędzi, jaka jest tak naprawdę konkretna różnica? Kodowanie za pomocą GWT sprawia wrażenie pracy z frameworkiem tak samo, jak z innymi opcjami.
Eelco



Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.