qualche esperienza con “Play” Java quadro di sviluppo web? [chiuso]

https://stackoverflow.com/questions/1597086

22-09-2019
|

Domanda

Ho appena incappato il seguente quadro java web nuovo: Gioca

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

con un elenco come sorprendente di caratteristiche, io sono praticamente sorpreso non ho sentito parlare prima ...

Suona come lo sviluppo Java Web terra promessa ...

Qualcuno ha provato? una vera e propria esperienza con esso? pensi che valga la pena studiarlo?

Soluzione

Sono d'accordo con Jason che il gioco potrebbe solo dimostrare di essere migliore di Grails. Con quattro progetti Grails sotto la mia cintura (preceduto da due progetti Tapestry e un progetto Wicket), sto seriamente guardando gioco successivo.

Una delle cose che ho pensato che era più cool Grails è che "Groovy di tutto". Cioè, si utilizza Groovy di scrivere tutto (tranne il codice HTML e il CSS) - domini, controller, servizi, modelli di pagina (SPG), librerie di tag, Hibernate API (GORM), test di unità (gunit), e costruire gli script ( GANT). Si può anche scrivere script di shell in Groovy. Così, essendo in grado di codificare tutti gli aspetti di un app che utilizzano un unico linguaggio di nuovo sembrava una semplificazione che era attesa da tempo - hearkening indietro ai giorni della scrittura applicazioni desktop in un unico linguaggio come C ++ o Delphi. Tuttavia, ho imparato che una taglia non va bene per tutti qui.

Per uno, il supporto IDE per Groovy non è grande. IntelliJ fa il lavoro migliore, ma con Groovy essendo dinamico, si può solo andare così lontano. Gli strumenti di refactoring Non (non può) catturare tutto, quindi non ci si può fidare al 100%. Questo significa che bisogna essere particolarmente vigili con unit testing. Anche qui, perché Grails si basa tanto sulla dinamica "magico" che avviene in fase di esecuzione, il testing di unità Grails deve contare su un vasto strato scherno di emulare, e quello strato beffardo è eccentrico. Un terzo problema è che gran parte del cosiddetto codice Groovy che si sta scrivendo è in realtà di dominio-specifici del linguaggio (DSL) del codice. (Per fare una lunga storia breve, DSL sono di breve mano Groovy, approfittando del fatto che in Groovy e il lotto della sintassi è opzionale.) Grails usi diversi DSL per varie configurazioni, la mappatura URL, ecc ed è incoerente. Come di specificare le impostazioni log4j, per esempio, sembra niente come il modo di specificare le fonti di dati, e non sembra che il puro Java su cui si basa Groovy. Quindi, la promessa di "Groovy di tutto" cade a pezzi in ogni caso.

Stando così le cose, non vedo dove il gioco di squadra è venuta da.

Tornando al normale Java per i domini, controller, servizi e JUnits ha un senso. Tipizzazione forte significa che l'IDE può aiutare con affidabile Inteli-senso, il codice di navigazione, refactoring, ecc (e quindi non c'è bisogno di pagare per IntelliJ se sei felice con Eclipse.) Dover scrivere codice più dettagliato al fine di ottenere indietro un forte sostegno strumento sembra un buon affare per me in questo momento. Vedremo.
mi piace che ho ancora da utilizzare Groovy nei modelli di pagina. Ho paura che io possa finire per mettere più codice nei modelli di quanto dovrei, però.
Non ho esperienza con JPA, ma sembra che è abbastanza vicino a quello che GORM fa per me, in modo che è cool.
Il supporto Primavera CIO in Grails è completamente trasparente, mentre il supporto del gioco sembra il minimo; tuttavia, penso che CIO è il modo abusata e io sono disposto a mano il codice una mappatura XML primavera in occasione rara che ho davvero bisogno di uno. (Una delle mie domande aperte è che sto supponendo che APP ha il supporto delle transazioni ed è per questo gioco non ha bisogno di Primavera che, come Grails fa, no?)
Non sono mai stato un fan di Python, così ho cringed quando ho letto che il gioco utilizza Python per i suoi script di compilazione. Ma sono d'accordo che gli script GANT Grails' corrono piuttosto lento. Inoltre trovo che, mentre GANT è un enorme miglioramento rispetto XML ANT, è ancora difficile per avvolgere la testa intorno ai concetti ANT. Gli script Grails GANT sono piuttosto contorto. Così, andrò ad esso con una mente aperta.
Il modello Play "modulo applicativo" suona per essere proprio come modello 'plug-in' Grails, in modo che è cool.
Sono abbastanza impressionato con la documentazione Play che ho letto finora. Ho avuto un enorme numero di domande che vanno in, ma la metà di loro hanno risposto destra fuori del blocco.

Io riferire più tardi, come mi tuffo profondo nel.

Altri suggerimenti

Ho provato Play e sono impressionato: si fa un grande lavoro di fornire un modello di sviluppo utile che è molto più semplice di quanto la maggior parte dei quadri. Più di ogni altra cosa, la capacità del runtime in 'modalità di sviluppo' per analizzare i file .java è direttamente vale molto: basta ricaricare la pagina Web nel browser senza eseguire uno script di build o in attesa di una ridistribuzione vale un sacco di velocità di sviluppo. I messaggi di errore visualizzati nel browser sono davvero buona.

Un'altra cosa che mi ha colpito è stato l'estetica complessiva: forse è una piccola cosa che l'applicazione esercitazione in realtà sembra buono (sia il codice e la progettazione di pagine web), ma questo si estende a tutto il quadro, l'API così come la documentazione.

Dopo sollecitazione da un collega ho guardato, seguito il tutorial, e stato catturato. Ottenere un feedback immediato direttamente nel tuo browser significa che non c'è bisogno di usare un IDE. Amo Eclipse, ma diciamocelo: dopo aver aggiunto alcuni extra, non è stabile come un editor di testo semplice. Su un Mac con TextMate si può anche cliccare sul messaggio di errore nel browser e TextMate si apre con il cursore su quella linea.

Test in gioco è anche molto ben fatto, con una sola premere il pulsante si esegue unit test, test funzionali e test Selenium-based.

Il gioco è interessante perché è ancora piccolo e semplice. Esso utilizza solo formica per costruire e lo fa in 25 secondi. Contribuire alla bella documentazione è una questione di modificare i file .textile e ricaricare i documenti in qualsiasi applicazione di gioco.

E 'così che ho finito in una missione per tradurre il tutorial per utilizzare Scala, aggiungendo al supporto Scala dove necessario per ottenere il più piacevole possibile.

mi piace, lo sto usando per i piccoli progetti e finora sembra perfetto per il lavoro. Tuttavia, c'è una cosa che mi manca molto che è stato lasciato fuori di proposito: Servizio / DAO / modello di separazione strati! Documentazione lo dice chiaramente, uno degli obiettivi del gioco è quello di evitare il "modello di dati anemico": http://www.playframework.org/documentation/1.0.1/model

ma nella mia esperienza il classico servizio / DAO / modello di separazione strati consente di risparmiare tonnellate di tempo di sviluppo in cui l'applicazione ha bisogno di essere riscritta! Con Play sei bloccato con metodi statici che si basano sulla gestione e la peculiarità specifica operazione-Play ...

Tuttavia, molti pollici in su per: velocità di sviluppo, il codice pulizia, e alla fine ... divertimento

Ho usato Grails, Tapestry 4/5 e Java diritto / JSP / Primavera / Hibernate.

Credo che questo sta andando nella giusta direzione per la prima volta in un tempo lungo. Grails è stato davvero un buon primo passo, ma Play! assomiglia a qualcosa che potrebbe davvero hanno le gambe. Supporto Scala è venuta in 1.1. Se c'è una possibilità che posso scrivere i miei controller / dominio in Clojure, sto venduto;)

da un anno e nessun bug visibile dopo 18 piccole uscite, usiamo giocare! 1.2.4 in una produzione un'applicazione intranet "assenze" per una scuola (attori:> 100 insegnanti,> 700 studenti, administrativ squadra). lato client è stato scritto con FLEX 4.6 da Adobe (molto bella vista). I dati sono inviare e ricevere in formato AMF3 (modulo cannella). Usiamo un proprio livello semplice dao sulla base di JPA EclipseLink e MySql per il DB. L'applicazione è memorizzato su un server virtuale Linux. Sono uno sviluppatore ventaglio molto of Play per la sua semplicità e il suo approccio molto produttivo.

Mi piace l'aspetto del gioco, ma non l'ho provato. Dalla scansione attraverso il docs una cosa che mi ha colpito è stato il pesante uso di metodi statici. Da un punto di vista unit testing questo rende sempre le cose molto più difficile (sto pensando deride), ed è una partenza dal approccio OO-ovunque in sviluppo tipico Java. Forse questo è il punto, ma è solo una cosa che mi ha fatto un po 'meno entusiasta ...

Attualmente creare applicazioni Web sul posto di lavoro utilizzando il framework di gioco che fa massiccia elaborazione dei dati. Devo dire che la velocità che il gioco offre solo è significativa e più di quello che RoR può fornire. Inoltre, il gioco è un framework basato su Java e quindi Multi-Threading può essere fatto facilmente. Avanti è la pura prestazione che si ottiene quando si utilizzano moduli Java-based come Japid e Netty con play.It è come una quantità infinita di tweaking può essere fatto per le prestazioni. Dovete assolutamente provare a mio parere.

sto usando Giocare in un piccolo progetto, e sembra essere esattamente quello che hanno detto a proposito. Ma una caratteristica penso che dovrebbe essere presente di default nel quadro: capacità di lavorare con più di un'origine dati (ad esempio, utilizzare più di una schema di database). Questa è la caratteristica manca solo che ho trovato fino ad ora.

Saluti, Uilian.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow