Differenza tra Apache Tapestry e Apache Wicket

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

Domanda

Apache Wicket ( http://wicket.apache.org/ ) e Apache Tapestry ( http://wicket.apache.org/ ) sono entrambi i framework web orientati ai componenti s - contrario a framework basati sull'azione come Stripes - dalla Apache Foundation. Entrambi consentono di creare la propria applicazione da componenti in Java. Sembrano entrambi molto simili a me .

Quali sono le differenze tra questi due framework? Qualcuno ha esperienza in entrambi? In particolare:

  • Come sono le loro prestazioni, quanto può essere personalizzata la gestione dello stato, possono essere usati senza stato ?
  • Qual è la differenza nel loro modello di componente?
  • Cosa sceglieresti per quali applicazioni?
  • Come si integrano con Guice, Spring, JSR 299?

Modifica : ho letto la documentazione per entrambi e ho usato entrambi. Non è possibile rispondere alle domande in modo sufficiente leggendo la documentazione, ma dall'esperienza derivante dall'utilizzarle per qualche tempo, ad es. come utilizzare Wicket in modalità stateless per siti ad alte prestazioni. Grazie.

È stato utile?

Soluzione

Alcune differenze rilevanti come le vedo io:

  • Tapestry utilizza una pagina semi-statica struttura, dove puoi lavorare condizionali e loop da raggiungere comportamento dinamico. Wicket è completamente dinamico; puoi caricare componenti dinamicamente, sostituirli in fase di esecuzione, ecc. Le conseguenze di questo è che Tapestry è più facile ottimizzare, e che Wicket è di più flessibile nel suo utilizzo.
  • Entrambi i framework sono approssimativamente ugualmente efficienti in esecuzione, ma Wicket conta archiviazione lato server (per impostazione predefinita il file pagina corrente nella sessione e passato pagine in una "cache di secondo livello" che è predefinito un file temporaneo nel file sistema). Se questo ti disturba, pensa su quante sessioni simultanee ti aspetti di avere nelle ore di punta e calcolare con dire ~ 100 kb per sessione (che probabilmente è nella parte alta). Ciò significa che puoi correre all'incirca supportare 20k sessioni simultanee per 2GB. Dì 15k perché ne hai bisogno memoria anche per altre cose. Di ovviamente, uno svantaggio della memorizzazione lo stato è che funzionerà solo bene con affinità di sessione, quindi questo è un limitazione quando si utilizza Wicket. Il framework ti fornisce un mezzo per implementare pagine senza stato, ma se stai sviluppando completamente apolide applicazioni che potresti prendere in considerazione a quadro diverso.
  • L'obiettivo di Wicket è supportare la tipizzazione statica nella misura massima, mentre Tapestry si occupa principalmente di salvare righe di codice. Quindi con Tapestry la tua base di codice è probabilmente più piccola, il che è buono per la manutenzione, e con Wicket, sei molto tipizzato staticamente, il che semplifica la navigazione con un IDE e il controllo con un compilatore, che è anche buono per la manutenzione. Qualcosa da dire per entrambi imho.

Ormai ho letto alcune volte che la gente pensa che Wicket funzioni molto con l'eredità. Vorrei sottolineare che hai una scelta. Esiste una gerarchia di componenti, ma Wicket supporta anche la composizione attraverso costrutti come IBehavior (in cima al quale, ad esempio, è costruito il supporto Ajax di Wicket). Inoltre hai cose come convertitori e validatori, che aggiungi ai componenti, a livello globale, o anche come preoccupazione trasversale usando alcuni degli ascoltatori di fase forniti da Wicket.

Altri suggerimenti

RIVEDUTO dopo aver studiato Tapestry 5.

L'obiettivo di Wicket è un tentativo di rendere lo sviluppo web simile alla GUI desktop . Sono riusciti a farlo davvero bene a spese dell'utilizzo della memoria (HTTPSession).

L'obiettivo di Tapestry 5 è rendere molto ottimizzato (per CPU e memoria) framework web orientato ai componenti.

Il vero grande trabocchetto per me sono state le risposte " Wicket supporta componenti senza stato! " agli argomenti "Wicket ha fame di memoria". Sebbene Wicket supporti effettivamente componenti senza stato, essi non sono "al centro dello sviluppo di Wicket". Ad esempio un bug in StatelessForm non è stato risolto da molto tempo - vedi StatelessForm - problema con i parametri dopo la convalida fallisce .

  • IMHO che utilizza Wicket è un po 'più entusiasta fino a quando non si ottimizzerà / perfezionerà i parametri dell'applicazione Web
  • IMHO Wicket è più difficile da studiare se hai programmato applicazioni web e vuoi pensare in termini di elaborazione delle richieste
  • Tapestry 5 carica automaticamente le classi dei componenti non appena le cambi. Entrambi i framework ricaricano il markup dei componenti.
  • Wicket force markup / separazione dei codici , Tapestry 5 ti dà solo questa abilità. Puoi anche usare una sintassi meno dettagliata in Tapestry 5. Come sempre questa libertà richiede più cautele.
  • Il core di Wicket è più facile da eseguire il debug: i componenti utente si basano sull'ereditarietà mentre i componenti utente di Tapestry 5 si basano su annotazioni. Dall'altro lato ciò potrebbe rendere le transizioni alle versioni future più facili per Tapestry che per Wicket.

Sfortunatamente Tutorial di Tapestry 5 non sottolinea che un esempio di codice di Tapestry come 't : loop source = " 1..10 " ... 'può essere una cattiva pratica. Quindi, alcuni sforzi dovrebbero essere fatti nello scrivere convenzioni / buone pratiche sull'uso di Tapestry se la tua squadra non è molto piccola.

I miei consigli :

  • Usa Wicket quando la struttura delle tue pagine è molto dinamica e puoi permetterti di spendere 10-200 Kbs di memoria HttpSession per utente (questi sono numeri approssimativi).
  • Usa Tapestry 5 nei casi in cui hai bisogno di un uso più efficiente delle risorse

Penso che Wicket sia un framework più semplice da usare.

Inoltre, Wicket consente il ricaricamento della classe tramite il sistema di sostituzione hot-code dell'IDE. Questo è tutto ciò che è necessario affinché Wicket esegua le versioni modificate delle classi di un'applicazione attualmente in esecuzione. Le solite restrizioni si applicano per la sostituzione di hot-code, come la necessità di essere eseguito in modalità Debug (Eclipse) e di non essere in grado di modificare gli aspetti strutturali di una classe (ad esempio il nome della classe, la modifica delle firme dei metodi ecc ...).

Non mi piace il modello di programmazione di Tapestry e conosco molti sviluppatori che abbandonano Tapestry a causa di troppi cambiamenti e incompatibilità nello sviluppo. Vedi: http: //ptrthomas.wordpress .com / 2009/09/14 / perfbench-update-arazzo-5-e-graal /

Wicket è un ottimo framework web. Meglio di tutto quello che so. Lo uso dalla versione 1.3 e ottengo sempre quello che voglio. Wicket ha un'eccellente integrazione con Spring: basta usare l'annotazione @SpringBean nel tuo codice per iniettare qualsiasi bean di primavera nelle tue classi.

Prova http://incubator.apache.org/click/ . È un fantastico framework web Java. Alcune persone lo chiamano & # 8220; Wicket reso giusto & # 8221; ; -)

Come ho detto quando la versione 4.1 era la versione ufficiale stabile:

Dovresti dare una buona occhiata alla storia dello sviluppo di Tapestry prima di impegnarti a usarlo. Tapestry ha fatto molti aggiornamenti non compatibili, senza alcuna continuazione del supporto delle versioni precedenti. Le patch per 4.1 non vengono più elaborate entro un lasso di tempo ragionevole. A mio avviso, ciò non è accettabile per la versione ufficiale stabile.

Impegnarsi a usare Tapestry 5 significa:

dovresti diventare un committer; devi stare al passo con tutti i nuovi sviluppi, abbandonare le vecchie versioni il più velocemente possibile; mantieni tu stesso versioni stabili.

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