Empecé a jugar con el marco de juego recientemente y realmente disfruto de la simplicidad.¿Por qué el marco de juego no está construido sobre la API de Servlet?
Pero una pregunta persistente que he tenido es ¿por qué se evita la especificación de servlet todos juntos? ¿Cuál fue la principal motivación detrás de tal decisión arquitectónica?
Desde el FAQ
Somos plenamente conscientes de que hicimos opciones que son bastante poco común en el mundo Java, y que la reproducción no ciegamente a todas las buenas prácticas de la llamada Java ' '. Pero todos los miembros del equipo Play son desarrolladores con experiencia en Java y somos totalmente conscientes de las elecciones que hicimos y las reglas que rompieron.
Java en sí es un lenguaje de programación muy genérico y no originalmente diseñado para el desarrollo de aplicaciones web . Es muy diferente a escribir una biblioteca genérica y reutilizable de Java y crear una aplicación web . No es necesario que una aplicación web diseñada para sea reutilizable. Necesita menos abstracción , menos configuración. existe la posibilidad de reutilización para las aplicaciones web , pero a través del servicio web API en lugar de la integración del nivel de idioma .
Cuando el tiempo de desarrollo tiende a CERO que pueda concentrarse en sus características de la aplicación y experimentar rápidamente, en lugar de intentar abstractos cosas para futuros desarrollos.
Play! las aplicaciones se pueden implementar como aplicaciones web en otros contenedores de servidores web, pero están diseñadas principalmente como un marco de pila completo; Juega es la plataforma. Y, en mi opinión, esto es lo que lo hace hermoso y rápido.
Pago Guillaume Bort's blog. (Fundador de Play! Framework). Él lo explica todo en su blog.
EDIT: El enlace ha cambiado, gracias procrastinate_later
¿Sería esto válido con el procesamiento asíncrono en servlet 3 api? –
@lamalama esa es una pregunta sin sentido. Si juego! es independiente de la API de Servlet, es independiente de la API de Servlet. – EJP
Su enlace ahora está roto, pero creo que encontré la entrada del blog aquí. http://guillaumebort.tumblr.com/post/558830013/why-there-is-no-servlets-in-play –
¿Cómo está esto específicamente relacionada con la API servlet? –
Usted preguntó: "¿Cuál fue la principal motivación detrás de una decisión arquitectónica de este tipo?", Y respondí: "Play * is * the platform". No solo querían convertirlo en un marco, o en algún contenedor, sino en una aplicación de pila completa, incluido el servidor web y todo. La conclusión es que simplemente no se puede comparar Play con la especificación de servlet porque aparte de ser Java, no comparten mucho en común (si no es que nada). –
No estoy seguro de que te sigo. En primer lugar, Play es un framework - sistema de software que es extensible y documenta claramente los puntos de extensión. En segundo lugar, no estoy comparando el juego con los servlets (eso sería una tontería). Me estoy preguntando por qué omitir el servlet API. –