Web Frameworks: ¿En qué se diferencia el juego de Spring MVC?

Question

El Play Framework ofrece la siguiente visión general rápida, pero con la excepción del motor de plantillas maravilloso (que se puede obtener en la primavera de MVC si lo desea), la primavera parece ofrecer todas las mismas características y más ...

• ¡Arregla el error y vuelve a cargar! ¡Edite sus archivos Java, guarde, actualice su navegador y vea los resultados inmediatamente! No es necesario compilar, implementar o reiniciar el servidor. Spring hace esto, lo que puede ser molesto.

• Stateless model Play es un sistema real de "No compartir nada". Listo para REST, se escala fácilmente ejecutando varias instancias de la misma aplicación en varios servidores. Las aplicaciones Spring típicas tienen un nivel de aplicación sin estado; no es puramente RESTful a menos que quieras, pero Spring está "listo para descansar".

• Sistema de plantilla eficiente Un sistema de plantillas limpio basado en Groovy como lenguaje de expresión. Proporciona herencia de plantilla, incluye y etiquetas. Spring usa Java, pero Groovy también es una opción.

• errores resolver rápidamente Cuando se produce un error, el juego se muestra el código fuente y la línea exacta que contiene el problema. Incluso en plantillas. Spring hace esto también.

• Todo lo que necesita para crear una aplicación web fresco proporciona integración con Hibernate, OpenID, Memcached ... Y un sistema de plugins. Spring se integra con todo y más.

• puro Java Code con Java, utilice cualquier biblioteca de Java y desarrollar con su IDE preferido. Se integra muy bien con eclipse o netbeans. Spring es también Java puro.

• realmente rápida inicia rápidamente y corre rápido! Subjetivo, pero Spring es bastante rápido.

Así que lo que hace el Marco de Juego realmente hacen de manera diferente a Spring MVC?

Answer 1

Me parece muy gracioso el reclamo de "pure Java" en ambos lados.

Por supuesto, no es realista que un proyecto use absolutamente nada más que Java. Aún así, una etiqueta de "Java puro" debería tener algunos estándares, no creo que ninguno de los marcos califique.

Play realmente modifica la semántica del lenguaje Java. Eso está bien, siempre que esté claramente especificado. Si haces una manipulación de código de bytes, sé honesto al respecto. Por lo general, se hace mediante el truco de AOP-ish, los métodos de instancia están decorados con comportamientos adicionales, sus comportamientos manifiestos, estos escritos en el código, generalmente se conservan. Esto no es demasiado difícil de aceptar, podemos pretender que nuestro código está subclasificado por el marco y nuestros métodos son anulados con un comportamiento adicional.

En Play, un método estático llamando a otro método estático en la misma clase puede tener efectos mágicos, y el comportamiento no es como una llamada a un método. Ese es un gran problema, si un programador Java ya no puede estar seguro de lo que es una llamada a un método estático.

Spring - bueno, su parte de Java todavía es pura Java, está bien. Pero es tan mágico (del punto de vista de Java), y depende tanto de un armazón pesado, llamar a Spring "puro Java", es como llamar a una hamburguesa "puro vegetal" si pasamos por alto la carne. La carne es la mejor parte!