2011-12-28 34 views
7

Ok, sé que hay hilos similares pero creo que este es distinto. En primer lugar, vengo del mundo de desarrollo de escritorio de C++ tan desnudo conmigo si no obtengo toda la terminología correcta.frameworks Java WEB MVC "tranquilos"

La aplicación que estoy desarrollando será "receptiva", realizará una comunicación asincrónica y pasará una gran cantidad de JSON de un lado a otro.

Necesito un framework web MVC en Java que soporta

1) Cantidad mínima de la hinchazón y "detrás de las escenas de la magia". Con cualquier marco, siempre hay una compensación entre la funcionalidad del marco frente a la complejidad. Pero, cuando llegue el momento en que enfrente un problema y tenga que "luchar contra el marco" (y ese momento siempre llega), quiero que sea una pelea justa. Minimizar el tamaño del marco aumenta la probabilidad de una pelea justa.

2) Soporte nativo RESTFUL. Es decir. enrutar verbos html y realizar negociación de contenido.

3) Soporte directo para el procesamiento JSON. Usar un procesador json arbitrario de mi elección, es decir, jackson o gson e.t.c ..

4) Soporte de persistencia directo, p. JPA e.t.c.

5) Algunos sistemas de plantillas, p. Ej. freemarker, velocity e.t.c.

6) de autenticación nativo/autorización esquema de seguridad con soporte para una "basada en roles" seguridad o integrar fácilmente con la seguridad de primavera

Todo lo anterior debe integrarse en el marco. No en un módulo de terceros contribuido por el usuario que se pudre cuando aparece una nueva versión del framework.

Me senté un día y experimentado y ha encontrado los siguientes candidatos

Spring MVC 3

1) Para obtener el proverbial "Hola Mundo" ejemplo en funcionamiento en Spring MVC 3 que necesitaba las siguientes tarros:

  • org.springframework.beans-3.1.0.RELEASE.jar
  • org.springframework.expression-3.1.0.RELEASE.jar
  • org.springframework.asm-3.1.0.RELEASE.jar
  • org.springframework.context-3.1.0.RELEASE.jar
  • org.springframework.core-3.1.0.RELEASE.jar
  • org.springframework.web-3.1.0.RELEASE.jar
  • org.springframework.web.servlet-3.1.0.RELEASE.jar

Y finalmente algunas definiciones en el archivo XML, "despachador-servlet .xml ". No sé si eso explica BLOAT o demasiada magia detrás de escena.Pero no me da una sensación cálida y difusa de estar en control somehwat

2) Spring 3 soporta esto y de la examples lo vi no se ve muy desagradable

3) compatibles, sino de la enlace en (2) parece que el procesamiento de json está limitado al uso de la biblioteca de jackson. Al menos, si quieres usar las anotaciones mágicas para la negociación de contenido.

Cita:

"bajo las sábanas, Spring MVC delegados a una HttpMessageConverter para realizar la serialización En este caso, Spring MVC invoca un MappingJacksonHttpMessageConverter integrado en el procesador Jackson JSON Esta aplicación se activa automáticamente.. cuando usa el elemento de configuración mvc: anotación-driven con Jackson presente en su classpath ".

Una pequeña señal de advertencia para mí. Me gustaría tener un control programático claro sobre qué procesador JSON estoy usando. Tal vez me falta algo aquí. Esto califica como no deseado "detrás de la magia escenas" en mi libro

4) Sí

5) Sí

6) Sí

Marco de Juego

1) Versión 1.2 pesaba 88,5 MB en mi disco. No se ejecuta en el contenedor de servlets, por lo que obtener el ejemplo de Hello World y ejecutarlo fue fácil comparado con la primavera, donde incluso averiguar qué jarras necesitaba estaba envuelto en secreto. Obviamente, muchas cosas ocurren detrás de escena en el juego. Creo que todo lo que puedo esperar es que no haga más de lo necesario. Y que la arquitectura es sensata. Pero, cuando tenga que luchar contra el marco algún día, ¿estaré muerto cuando llegue? Quién sabe ...

2) Sí y lo hace elegantemente. Pulgares hacia arriba.

3) Sí, pero usa gson debajo de las fundas. Nuevamente, ¿por qué no puedo controlar esto programáticamente? Afortunadamente, uno puede pasar un serializador arbitrario a gson para anular el predeterminado. E I piensa que ese parámetro se correlaciona con el segundo parámetro de la función nativa play jSON(). Así que el juego pasa con medio pulgar hacia arriba.

4) Sip. Tiene un módulo JPA

5) Sip. Utiliza groovy. Bien por mi.

6) Debería ser posible combinando los módulos de seguridad y deadbolt. No sé qué tan bien se compara con la seguridad de primavera. No veo ningún soporte incorporado para el cifrado de contraseñas y los me gusta. Y no tengo idea de lo difícil (si es posible) sería integrar con seguridad de primavera. ¡No sé si me sentiría cómodo implementando datos confidenciales y confiando en la obra! marco de seguridad. Probablemente tendrían que construir algo encima.

Restlet

Tal vez un candidato peculiar, ya que está comercializado para ser utilizado por los "servicios web" inquietos. Pero para mis puntos (1) - (6) y mi tipo de aplicación donde la mayor parte de la interacción del usuario es asincrónica, parece una buena opción.Puedo ejecutarlo en recursos estáticos o contenido generado dinámicamente y escupir cualquier tipo de contenido.

1) Restlet 1.1.1 es de aproximadamente 54 MB. Echó un vistazo al ejemplo de Hello World. Me gustó la ausencia de archivos XML. Y al igual que jugar, tiene su propio servidor (conectores de embarcadero). El ejemplo de Hello World se veía muy limpio y fácil.

2) Sí, y el enfoque es muy "programático"

3) Sí, pero parece que sólo a través de un jackson extension module. Dada la naturaleza programática de este marco, parece probable que haya otras opciones, pero no encontré nada en la documentación o en los foros de los grupos de usuarios.

4) Se describe a sí mismo como "persistente agnóstico". OK, eso es bueno, supongo. Pero quiero persistir y no reinventar la plomería por mi cuenta. O al menos quiero un poco de cómo mostrar que se PUEDE hacer con un poco de esfuerzo. Hay un módulo jpa de terceros pero está basado en restlet 1.0. Restlet tiene un módulo de primavera, así que quizás me puede integrar con la materia de la persistencia de primavera ...

5) Sí, hay una extensión FreeMarker

6) tiene un esquema nativo para esto. A primera vista, no tan "rico" como la seguridad de primavera. De nuevo, ¿tal vez puedo integrarme?

RESUMEN

Spring MVC 3: Soporta todos los requisitos, tal vez con la excepción de (1). La única preocupación que tengo es que parece complejo y tengo una vaga sensación desagradable de no tener el control. Realmente no quiero quedar "atascado" por el framework más adelante a medida que crece mi aplicación.

Reproducir: Una experiencia muy agradable. Diversión incluso. Si sólo el esquema de seguridad era más avanzada, o si por lo menos pudiera integrarse con la seguridad de primavera (y encontrar documentación sobre cómo hacerlo)

Restlet: Por alguna razón este marco resonó en mí. El enfoque programático induce una sensación de control. Pero si no puedo hacer persistencia de una manera fácil-fácil entonces es un no ir. Realmente no puedo entender por qué esto no está incorporado. ¿No todo el mundo necesita esto?

  • ¿Qué dicen las personas que han usado cualquiera de los marcos anteriores?
  • ¿Son precisas mis observaciones?
  • ¿Dejé fuera un marco que debería estar aquí?
  • ¿Alternativas?

Saludos

+0

Si usted no está limitado a Java, pero también considera maravilloso, es posible que desee echar un vistazo a [Griales] (http://grails.org/) – Robin

Respuesta

1

sólo puedo hablar por el resorte aquí.

Cuando me vi obligado a usar Spring para un proyecto que no era REST el año pasado, me encogí. No solo tuve unos pocos días para aprender lo básico, no me gustó toda la "magia" que tenía, ni estaba familiarizado con los principios de IoC.

Pero creció en mí. Creció en mí bastante rápido también. Desde entonces, he utilizado Spring para todo tipo de proyectos web, incluido uno que expone una API RESTful.

Las fortalezas de Spring desde mi punto de vista son: a) es bastante liviano y generalmente se mantiene alejado de ti una vez que tienes las cosas configuradas, b) MUCHAS ejemplos y una gran comunidad de apoyo, c) haciendo REST es muy fácil, una vez que tienes la configuración correcta, d) un diseño API que hace llorar a los dioses con alegría, y e) IoC cambia la vida.

Hablando de su preocupación con la hinchazón ... He utilizado otros frameworks web para Java, y Spring es el menos pesado de todos ellos IMO. Puede parecer mucho, pero en realidad no lo es. Comparado con Struts y Seam (ambos de los cuales todavía tengo pesadillas), Spring es antitético a la hinchazón. Además, el IoC te permitirá escapar sin tener que escribir toneladas de repeticiones, haciendo que tu aplicación sea menos ruidosa también.

Menciona que no quiere empantanarse con el marco a medida que crece su aplicación. Esto no sucederá en primavera, te lo garantizo. Está diseñado para mantenerse fuera del camino y evitar que dependa de un marco. Su código, si está diseñado correctamente, podría dejar caer a Spring en el futuro por otra cosa sin muchas maldiciones y golpes. Favorece la convención sobre la configuración, lo que significa que lo común debería funcionar de la caja sin tener que jugar mucho. Para esas cosas que están fuera de la pared, te da suficiente cuerda para ahorcarte.

En resumen, consideraría mucho Spring.

0

Los dos que puedo recomendar es RESTlet 2.x, que uso en todos los proyectos. Y RESTEasy que estoy considerando usar en un próximo proyecto.

Lo que me gusta de RESTlet es que todo el enrutamiento se encuentra en un solo lugar. Es muy feature rich.

Lo que no me gusta de RESTEasy, y no lo he analizado tan profundamente, es que las Anotaciones tienen todo el enrutamiento esparcido por el código base de cada método, de lo que podrían ser muchas clases. No tenerlos a todos en un solo lugar hará que el mantenimiento sea más difícil.

Por qué todavía estoy considerando RESTEasy, está teniendo múltiples GET métodos por clase podrían reducir la explosión de clase resource que puede ocurrir en RESTlet.

Ambos cumplen con JAX-RS, si eso es importante, y cualquiera de los dos es una inversión sólida en tiempo y funcionalidad.

En cuanto a la creación de plantillas, use StringTemplate, aléjese de cosas como FreeMarker, solo conducen a un mundo de dolor en mantenibilidad.

3

la comparación entre Spring y Play ahora está muy desactualizada, ya que Play 2.0 se ha reescrito en Scala y es mejor en casi todas las formas posibles.

Compruébelo usted mismo: http://www.playframework.org/

Cuestiones relacionadas