Quale quadro dovrei scegliere - Seam, Wicket, JSF o GWT? [chiuso]

StackOverflow https://stackoverflow.com/questions/745029

Domanda

sto discutendo se utilizzare Seam, Wicket, JSF o GWT come base per il mio livello di presentazione in un progetto Java.

ho ridotto la mia selezione di framework web Java fino a questo sottoinsieme sulla base di considerazioni di mercato del lavoro, novità della tecnologia e raccomandazioni da altri S.O. utenti.

Quali fattori devo prendere in considerazione nel decidere tra questi?

È stato utile?

Soluzione

L'unico uno di quelli che ho usato è JSF, quindi non sarà in grado di dare un feedback sugli altri, ma qui è il mio prendere su JSF. Nella mia esperienza, il minuto abbiamo convertito dal JSF in JSP per JSF in Facelets, la vita è ancora più facile, quindi mi concentrerò intorno facelets. Inoltre, sembra che Seam e JSF non si escludono a vicenda.

Pro:

  • Creare facelets componenti XHTML è semplice, che promuove il riutilizzo.
  • capacità di templating dignitoso utilizzando built in tag come ui: inserto, ui: include, e ui: decorare
  • Un facile accesso ai bean Spring attraverso volti-config
  • Valid base per cui gli sviluppatori web non hanno familiarità con Java può essere ancora efficace
  • Buona libreria di widget disponibili a Tomahawk / Trinidad

Contro:

  • richieste POST solo. Questo può rendere bookmarking difficile.
  • Non è incorporato ajax-y come GWT, ma questo può essere fissato se utilizzato con Seam

Sono affatto un esperto in JSF / Facelets, quindi sono sicuro che ci sono altri che ho perso. Speriamo che qualcun altro cercherà di esaminare.

Aggiornamento per JSF 2.0:

Altri suggerimenti

Ho usato GWT a partire dalla versione 1.4 e JSF in quanto la specifica 2.0 è venuto fuori.

GWT è un framework lato client, esso genera JavaScript da Java. L'architettura sarebbe un client-server puro, il che significa:

  • Best di utilizzare i servizi a grana grossa
  • Tutti gli oggetti che viaggiano per il lato client dovrebbero essere pienamente serializzabile (che significa non c'è carico pigri, o un motivo OpenSessionInView)
  • Dal momento che GWT 2.0 è possibile progettare il xhtml gui in uso, che è molto più facile per quanto riguarda lo styling e strutturazione HTML
  • GWT tende a favorire la buona architettura, se si rovinare tutto sarà male di refactoring
  • Perfect Supporto Storia (browser pulsante Indietro, URL segnalibro) è difficile , probabilmente avete a rotolare il proprio, anche se è facile incidere qualcosa di destra sulla parte anteriore

JSF è un framework basato su componenti, con un design vista-prima (code-behind, se volete):

  • E 'più facile fare un certo tipo di webapps (stateful, come carrello della spesa)
  • JSF + Seam sono suport per le conversazioni (si pensi pagine della procedura guidata simile che mantengono lo stato tra diverse pagine)
  • possono implementare OpenSessionInView, a seconda del vostro stack. Probabilmente non è consigliata se si usa EJB per il servizio / strato di business
  • JSF2 ha superba il supporto per AJAX, e con una suite di componenti come RichFaces si può costruire belle webapps
    • Ma se si vuole squisita comportamento javascript, dovrete scrivere qualche javascript
  • JSF traccia dello stato dell'interfaccia utente corrente nel client o server-side. Si tratta di un compromesso tra il traffico di rete o di memoria del server.

Riprendi:

  • GWT è più adeguata per il web Applicazioni (si pensi gmail) che richiedono le migliori prestazioni sul lato client. E 'facile scrivere componenti personalizzati (si scrive Java) e dal momento che il server-side è solo un livello di servizio si può essere completamente senza stato sul lato server.
  • JSF è più adeguato per le applicazioni per lo più CRUD che sono più adatti per le cose orientato ai componenti: pensare un sistema di prenotazione hotel / volo, un negozio online con un carrello della spesa, ecc

Grazie ragazzi per wicket rimanendo sobrio e mantenere su questa discussione. Sono un utente wicket e mi piace. Le mie ragioni principali sono:

  1. E 'un framework di componenti. Mi piace lavorare con i componenti in contrasto con pagine piene.

  2. posso lasciare che i progettisti lavorano sui modelli e sulle pagine come io lavoro sulle parti java

  3. Non c'è nulla di nuovo da imparare. Il suo "solo Java e solo HTML"

  4. Mi piace il suo meccanismo ajax Fallback. Dove non c'è supporto di JavaScript in un browser in particolare su dispositivi mobili, cade di nuovo in HTML puro e tutto funziona.
  5. La sua mancanza di configurazione XML è un plus
  6. Sostiene tutto quello che vorrei in un'applicazione web. per esempio la convalida, l'internazionalizzazione, sostegno per la schiena e il pulsante URL riposanti tra gli altri

La mia esperienza precedente è GWT e JSF 1.0

Seam è un framework applicativo, non proprio un livello di presentazione. È stato originariamente sviluppato per rendere JSF meno dolorosa, ma si è evoluto in un quadro più generale iniezione di dipendenza scopo.

Io credo che è possibile utilizzare Seam con JSF, Wicket e GWT. supporto JSF è primario ed eccellente; Non sono sicuro di quanto bene gli altri due sono supportati.

Dato che il fuoco dei vostri criteri sembrano essere la commerciabilità delle tue capacità, vorrei suggerire di provare Seam e JSF via Facelets. JSF è uno standard ben accettato e in realtà è piacevole da usare se si utilizza Facelets. Si possono avere funzionalità AJAX chiazza di petrolio tramite RichFaces e Ajax4jsf. Seam è stato più o meno standardizzato attraverso il JCP.

La mia esperienza è, in ordine cronologico:

servlet prime - (! Sì, è un sacco di duro lavoro, ma l'era primi giorni e siamo stati castori desiderosi)

JSP - ho pensato che fosse Neez Beez nel momento in cui è venuto fuori (se sapevamo solo;))

Echo - quadro impressionante, ma non per le pagine che hanno bisogno di essere motore di ricerca amichevole (stesso problema con GWT)

Wicket - quadro impressionante - gli sviluppatori a comprendere appieno il concetto di OO (a differenza di JSP e molti altri) e hanno applicato tutti i soliti convenevoli OO a questo quadro. Se apprezzate 'riusabilità', se apprezzate l'incapsulamento, se apprezzate la separazione degli interessi e se vi piace vincolare il proprio modello per il codice di interfaccia utente, senza doversi preoccupare di oggetto di smistamento e altri tali brutture allora questo è il quadro per te!

In uno scenario di lungo termine Mi consiglia di utilizzare le tecnologie supportate da una specifica solarium. Ciò ha finora dimostrato che invia più implementazioni conseguente scelta (implementazioni spesso anche open source), più comportamento tende ad essere molto ben definito.

Che vi aiuterà in uno scenario di mantenimento, che - si spera - il codice finirà anche nel tempo. codice ben scritto vive per sempre:)

In questo scenario particolare vorrei suggerire JSF. Ho provato solo l'attuazione Apache di 1,1, ma male per essere in cima JSP. Siamo di rivedere presto - mi aspetto di guardare in avere JSF sul facelets

.

Ho usato Wicket e GWT piuttosto pesantemente. Mai veramente imparato ad amare Wicket.

Il mio ego bloggato su di esso http://salk31.blogspot.com/ 2009/07 / wicket-ajax.html

Guardando GWT 2.0 uiBinder oggi mi ha ricordato quanto sia fastidioso era in Wicket di dover corrispondere l'albero componente XML con quello creato in Java. Lo spin GWT su questo aspetto di gran lunga migliore per me.

non ho usato Wicket per oltre un anno quindi forse hanno fissato un sacco di questo, ma dato browser moderno e il supporto JS non riesco a vedere il punto di fare tutto questo sul server (lo so, lo so i dati località).

Se si considera solo mercato del lavoro, si dovrebbe scegliere JSF. Ma, I belive che il futuro della RIA appartiene a GWT e GWT come le tecnologie lato client.

Credo che il rialzo più evidente di GWT, è meglio scalabile rispetto alle tecnologie di strato di presentazione lato server, come JSF, wicket. Perché, il server non ha bisogno di memorizzare lo stato del cliente e la potenza della CPU cliente anche sono utilizzati anche .. Si tratta di un enorme vantaggio, non avete bisogno di serializzare stato cliente tra computer server per achive sistema fault tolerant.

Lo so che è un po 'tardi, ma c'è già sacco di confronto su framewrok, espcially questo, wich è verificato durinf Devox 2010 conf:

http://www.devoxx.com/display/Devoxx2K10/ confrontando + JVM + Web + Frameworks

Questo dovrebbe aiutare a scegliere:)

Ho iniziato con JSF (1.1 e 1.2) ed è stato così doloroso che ho deciso di cambiare in prossimi progetti. Ho studiato un po 'e ho deciso di provare Wicket, ed era così un piacere. Anche io ho provato JSF 2, ma è ancora la stessa cosa.

Entrambi sono quadri di componenti, ma le cose con Wicket sono facili, mentre con JSF sono un disastro completo.

Wicket su JSF:

  • In Wicket HTML sono HTML. JSF ha i propri tag mark-up. Il h: dataTable (per le tabelle) è una sciocchezza. Credetemi, Sun ingegneri hanno dovuto essere ubriaco quando progettato esso.
  • Nella cose Wicket come la sicurezza,
  • Con JSF barra di navigazione mostra l'URL precedente. Davvero strano.
  • JSF mi sembra molto pesante, e con le librerie come Rich or Prime ancora di più.
  • A volte, sembra impossibile sapere che sta succedendo. Si finisce sempre urlare al vostro computer, perché non si conosce il motivo per cui JSF sta facendo.

JSF oltre Wicket:

  • In Wicket si sta andando a scrivere di più Java (il legame con HTML). Almeno, il vostro IDE fornirà supporto refactoring e la validazione.
    • gestione
  • Risorse in Wicket è un po 'complicato.
  • Non ci sono documentazione e supporto molto di più per JSF

Un difetto comune è che le dimensioni sono sessione è problema (perché i componenti grafici vengono memorizzati in là).

Tutto sommato, se si deve decidere solo tra Wicket e JSF non ci dubbio per me, Wicket .

JSF è deprecato (JSF non è nemmeno elencato come un quadro di riferimento per confrontare quando si confrontano evangelisti o parlare di framework web nel 2010).

Ora pieno fledge applicazioni su larga scala vengono creati utilizzando GWT, YUI, JQuery, ecc.

leggere alcuni articoli su google e, soprattutto, sarà evidente.

(tutti i lavori su JSF sono per supportare le applicazioni legacy).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top