alguna experiencia con el marco de desarrollo web "Play" java?

Question

acabo topé con el siguiente nuevo marco de Java Web: Juega

http://www.playframework.org/

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

con una lista tan impresionante de características, estoy bastante sorprendido de que no he oído hablar de antes ...

Suena como el desarrollo web java tierra prometida ...

ha tratado a nadie que? alguna experiencia real con eso? ¿Crees que vale la pena estudiarlo?

Answer 1

Estoy de acuerdo con Jason en que Play podría ser mejor que Grails. Con cuatro proyectos de Grails en mi haber (precedidos por dos proyectos de Tapestry y un proyecto de Wicket), estoy mirando seriamente Play ahora.

Una de las cosas que me pareció genial sobre Grails es que "todo es maravilloso". Es decir, utiliza Groovy para escribir todo (excepto el HTML y el CSS): dominios, controladores, servicios, plantillas de página (GSP), bibliotecas de etiquetas, Hibernate API (GORM), pruebas unitarias (GUnit) y compilaciones (GANT). Incluso puede escribir scripts de shell en Groovy. Por lo tanto, ser capaz de codificar todos los aspectos de una aplicación usando un solo idioma nuevamente parecía una simplificación que hacía tiempo que vencía, remontándonos a los días de escribir aplicaciones de escritorio en un solo idioma como C++ o Delphi. Sin embargo, he aprendido que un tamaño no encaja todo aquí.

Por un lado, el soporte IDE para Groovy no es genial. IntelliJ hace el mejor trabajo, pero con Groovy siendo dinámico, solo puede ir tan lejos. Las herramientas de refactorización no capturan (no pueden) todo, por lo que no puedes confiar en ellas al 100%. Esto significa que debe estar especialmente atento con las pruebas unitarias. Una vez más, dado que Grails depende tanto de la "magia" dinámica que ocurre en el tiempo de ejecución, la unidad de prueba en Grails debe confiar en una extensa capa de burla para emularla, y esa capa burlona es peculiar. Un tercer problema es que gran parte del llamado código Groovy que estás escribiendo es en realidad código de dominio específico del idioma (DSL). (Para abreviar, las DSL son short-hand Groovy, aprovechando el hecho de que en Groovy y gran parte de la sintaxis es opcional.) Grails utiliza diferentes DSL para diversas configuraciones, mapeo de URL, etc. y es inconsistente. La forma de especificar la configuración de log4j, por ejemplo, no se parece en nada a cómo se especifican las fuentes de datos, y tampoco se parece a la Java pura en la que se basa Groovy. Entonces, la promesa de "todo es maravilloso" se desmorona de todos modos.

Siendo ese el caso, veo de dónde viene el equipo de Play.

1. Volver al Java normal para los dominios, controladores, servicios y JUnits tiene sentido.Un tipado fuerte significa que el IDE puede ayudar de manera confiable con inteli-sense, navegación de código, refactorización, etc. (Y así no necesita pagar IntelliJ si está contento con Eclipse.) Tener que escribir un código más detallado para Ganar apoyo de herramientas fuertes parece ser un buen negocio para mí en este momento. Ya veremos.

2. Me gusta que sigo usando Groovy en las plantillas de página. Sin embargo, me temo que puedo terminar poniendo más código en las plantillas de lo que debería.

3. No tengo experiencia con JPA, pero parece que está muy cerca de lo que GORM hace por mí, así que es genial.

4. El soporte Spring IOC en Grails es completamente transparente, mientras que el soporte de Play parece mínimo; sin embargo, creo que el COI está demasiado usado y estoy dispuesto a codificar a mano un mapeo Spring XML en la rara ocasión en que realmente necesito uno. (Una de mis preguntas abiertas es que asumo que JPA tiene soporte para transacciones, por lo que Play no necesita Spring para eso, como hace Grails, ¿no?)

5. Nunca he sido fan de Python, así que me encogí cuando leí que Play usa Python para sus scripts de compilación. Pero estoy de acuerdo en que los guiones GANT de Grails se ejecutan bastante lento. Además, creo que, si bien GANT es una gran mejora con respecto a XML ANT, sigue siendo difícil entender los conceptos de ANT. Los guiones Grail GANT son bastante intrincados. Entonces, voy a entrar con una mente abierta.

6. El modelo Reproducir "módulo de aplicación" suena como el modelo de "complemento" de Grails, así que es genial.

7. Estoy bastante impresionado con la documentación de Play que he leído hasta ahora. Tuve una gran cantidad de preguntas, pero la mitad de ellas fueron respondidas de inmediato.

Voy a informar de nuevo más tarde como yo buceo profundo en

Answer 2

Utilicé Grails, Tapestry 4/5 y directamente Java/JSP/Spring/Hibernate.

Creo que esto va en la dirección correcta por primera vez en mucho tiempo. Grails fue realmente un buen primer paso, ¡pero juega! parece algo que realmente podría tener piernas. El soporte de Scala viene en 1.1. Si existe la posibilidad de que pueda escribir mis controladores/dominio en Clojure, estoy vendido;)

Answer 3

Me gusta el aspecto de Play, pero no lo he probado. Desde el escaneo a través de los documentos, una cosa que se destacó fue el uso intensivo de métodos estáticos. Desde el punto de vista de la prueba unitaria, esto siempre hace las cosas mucho más difíciles (estoy pensando en burlas), y es una desviación del enfoque OO-everywhere en el desarrollo típico de Java. Tal vez este es el punto, pero es algo que me hizo sentir un poco menos entusiasmado ...

Answer 4

he tratado de reproducción y estoy impresionado:. Lo hace un gran trabajo de la entrega de un modelo de desarrollo útil que es mucho más simple que la mayoría de los marcos '. Más que cualquier otra cosa, la capacidad del tiempo de ejecución en 'modo de desarrollo' para analizar directamente los archivos .java vale mucho: simplemente cargar la página web en el navegador sin ejecutar un script de compilación o esperar una nueva implementación vale mucho la velocidad de desarrollo. Los mensajes de error que se muestran en el navegador también son realmente buenos.

Otra cosa que me impresionó fue la estética general: quizás la aplicación tutorial realmente se vea bien (tanto el código como el diseño de la página web), pero esto se extiende a todo el framework, la API también como la documentación.

Answer 5

Después de pinchar de un colega lo miré, seguí el tutorial y me enganché. Recibir comentarios inmediatos directamente en su navegador significa que no tiene que usar un IDE. Me encanta Eclipse, pero seamos sinceros: después de haber agregado algunos extras, no es tan estable como un simple editor de texto. En una Mac con TextMate, incluso puede hacer clic en el mensaje de error en su navegador y TextMate aparece con el cursor en esa línea.

La prueba en el juego también está muy bien hecha, con un botón presione ejecutar pruebas unitarias, pruebas funcionales y pruebas basadas en selenio.

El juego es emocionante porque aún es pequeño y sin complicaciones. Usa solo una hormiga para construir y lo hace en 25 segundos. Contribuir a la hermosa documentación es una cuestión de editar los archivos .textile y volver a cargar los documentos en cualquier aplicación de reproducción.

Así es como terminé en una búsqueda para traducir el tutorial para usar Scala, agregando al soporte de Scala donde sea necesario para hacerlo lo más agradable posible.

Answer 6

Estoy usando Play en un proyecto pequeño, y parece ser exactamente lo que han dicho. Pero una característica que creo que debería estar presente por defecto en el marco: capacidad de trabajar con más de un origen de datos (por ejemplo, usar más de un esquema de base de datos). Esta es la única característica que falta hasta ahora.

Saludos, Uilian.

Answer 7

Me gusta, lo estoy usando para proyectos pequeños y hasta ahora parece perfecto para el trabajo. Sin embargo, hay una cosa que extraño mucho que se ha omitido a propósito: ¡Separación de capas de servicio/DAO/modelo! Documentación lo dice claramente, uno de los objetivos del juego es evitar el "modelo de datos anémico": http://www.playframework.org/documentation/1.0.1/model

pero en mi experiencia de la clásica separación de capas de servicio/DAO/modelo ahorra un montón de tiempo de desarrollo cuando la aplicación necesita ¡ser refactorizado! Con Play que está pegado con métodos estáticos que se basan en la gestión y peculiaridades transacción específica-Play ...

Sin embargo, muchos pulgar hacia arriba para: velocidad de desarrollo, la limpieza de código, y al final ... diversión!

Answer 8

Actualmente construyo aplicaciones web en el trabajo utilizando el marco de juego que hace un procesamiento masivo de datos. Debo decir que la velocidad que ofrece el juego solo es significativa y más de lo que RoR puede proporcionar. Además, el juego es un framework basado en Java y, por lo tanto, Multi-Threading se puede hacer fácilmente. Lo siguiente es el gran rendimiento que obtienes cuando usas módulos basados ​​en Java como Japid y Netty junto con el juego. Es como si se pudiera hacer una cantidad infinita de ajustes para mejorar el rendimiento. A debe probar en mi opinión.

Answer 9

Desde hace un año y no hay errores visibles después de 18 lanzamientos pequeños, utilizamos Play! 1.2.4 en una aplicación de intranet de "ausencias" de producción para una escuela (actores:> 100 docentes,> 700 estudiantes, equipo administrativo). El lado del cliente ha sido escrito con FLEX 4.6 de Adobe (vistas muy bonitas). Los datos se envían y reciben en formato AMF3 (módulo Cinnamon). Usamos una capa dao simple propia basada en JPA EclipseLink y MySql para DB. La aplicación se almacena en un servidor virtual Linux. Soy un desarrollador muy entusiasta de Play por su simplicidad y su enfoque muy productivo.