provides pom nfl java dependency-injection guice

pom - ¿Qué Java Web Framework encaja mejor con Google Guice?



guice provides (6)

Aquí hay un artículo sobre la integración de Guice con rayas

Estoy planeando comenzar un nuevo proyecto y estoy mirando los actuales frameworks web Java de última generación. Decidí construir mi aplicación alrededor de Guice, y es probable que use un ORM muy ligero como Squill / JEQUEL / JaQu o similar, pero no puedo decidir sobre el framework web. ¿Cuál se ajustaría mejor en un entorno tan ligero? ¿Y cuál se integra mejor con Guice?

Reuní algo de experiencia sobre este tema, ya que comencé a programar un nuevo proyecto en noviembre. El proyecto está en una etapa tardía ahora.

Para mí, las siguientes pautas de diseño fueron importantes:

  • Use una pila de tecnología moderna que sea divertida de usar y que sea de uso general en el futuro.
  • Reduzca el número de artefactos del proyecto: use anotaciones / código Java donde tenga sentido, omita XML.
  • Use marcos de código abierto
  • Tener una comunidad activa
  • No son etapa alfa
  • Son livianos
  • Evitar la duplicación de conceptos
  • Puedo explicar los conceptos en él a mis dos compañeros desarrolladores, quienes, a pesar de ser buenos programadores, nunca han usado inyección de dependencia (DI) o marcos web.
  • Puede servir como una base tecnológica para proyectos futuros

Google Guice como contenedor DI fue una opción obvia: claramente el mejor residente de DI, con brillantes desarrolladores y una buena comunidad. Cumple todos los puntos mencionados anteriormente.

Así que configuré mi stack de tecnología básica. Comenzó con Guice, agregó Hibernate para la persistencia (junto con warp-persist y warp-servlet ). Luego escribí algunos DAO básicos que seleccionan algo.

Luego traté de hacer lo siguiente: agregué un marco web diferente además de eso.

Creé una página simple con una tabla, poblada por el DAO, encabezados y un campo de texto con los cuatro marcos.

Estos fueron mis hallazgos al comparar los cuatro marcos.

XSLT y XStream son una especie de enfoque hardcore. No es realmente un marco, sino una tecnología viable completamente apátrida para aplicaciones de alto rendimiento. Esta fue de lejos la forma más rápida de servir la página de prueba. En modo de depuración, 3 ms en localhost versus alrededor de 30-50 ms con los otros framworks.

La integración de Guice fue relativamente sencilla y buena utilizando warp-servlet, lo que me permitió inyectar en servlets e inyectar httprequest, httpresponse, session en otros objetos, sin pasarlos. Desventajas: no hay comunidad en absoluto, ya que soy la única persona que consideraría esta pila. - sin componentes listos para usar.

Luego eché un vistazo a JSF y Guice: por supuesto, es posible poner el inyector en el contexto de servlet y usar guice como un localizador de servicio. Con el enfoque directo, es imposible inyectar los granos de respaldo en otro lugar. El uso de una solución de resolución personalizada resuelve esto parcialmente, pero luego pierde toda la integración IDE en sus archivos JSF además tendrá que usar feo FQN para sus beans de respaldo, o construir una cadena-> Guice key mapping en alguna parte. Ambos son feos como:

  • Ventajas: buena comunidad, muchos desarrolladores en el mercado de trabajo (no hay criterios para mí). No te despedirán por elegir JSF si algo sale mal.
  • Desventajas: trae su propio mecanismo de Inversión de control (IoC) que choca conceptualmente con Guice.

warp-widgets: Creé mi ejemplo simple usando esto por diversión; es etapa alfa temprana. Fue agradable de usar y sus componentes son fáciles de implementar y reutilizar por mi cuenta. Su objetivo es proporcionar HTML de tipo seguro con la integración perfecta de Guice. Dado que parecía que solo tenía un desarrollador activo en ese momento, que ahora está trabajando de forma convincente en Guice 2.0, diría que la comunidad es casi inexistente. Funcionó a las mil maravillas, era razonablemente rápido, pero hubiera sido probador alfa. Eso fue simplemente demasiado arriesgado para mí considerarlo para un proyecto comercial.

Apache Wicket: este proyecto primero me sorprendió con wicket-ioc y wicket-guice que se unieron en la descarga principal. La inyección de constructores en páginas web no es posible, solo establece + campo. Inyectar en las páginas web de Wicket es fácil, simplemente agregue @Inject a los campos que desea llenar, pero se supone que no debe entender cómo funciona en segundo plano . Cosas complicadas sucediendo. La inyección de páginas web es teóricamente posible, pero no la he usado una vez, ya que esto imposibilita el uso de URL montadas, además de que interferirá con el estado persistente / serializado. Los miembros inyectados de las clases se tratan de forma transparente con la serialización de la página web, que es necesaria para permitir el respaldo del navegador. Wicket utiliza cero artefactos externos: solo una pequeña configuración de las URL en una clase de aplicación. Entonces, toda la configuración se realiza en Java, lo que se adapta bien al modelo de Guice. Separación clara de HTML y Java. Es de código abierto al igual que la mayoría de los componentes que son numerosos y de buena calidad. Está disponible desde 2005 (?) Y es un proyecto Apache de alto nivel. Aunque es un marco rico en características, su API es razonablemente compacta (todas las clases básicas caben en un solo JPEG en mi pantalla). A diferencia de otros, no trae un mecanismo de IoC propio, sino que piensa en IoC como un servicio que puede ser provisto por Spring Framework , Guice, etc. y esa filosofía lo hace superior a la integración de Guice wrt. ¿Mencioné el soporte Ajax realmente inteligente y fácil?

Los marcos no están profundamente evaluados: tapices5: trae su propio IoC. Seam : no es un framework en sí mismo, sino un metaframwork que normalmente coincide con Spring, JSF. Hibernar. (Aunque Spring puede ser reemplazado teóricamente por Guice).

Resumen: de las estructuras evaluadas, Apache Wicket fue el ganador claro - con respecto a la integración de Guice + todos los demás criterios mencionados.

Además de nosotros dos, algunas otras personas han tenido este problema antes .

Un buen contenedor web ligero es simple . Es extremadamente eficiente y se puede usar con frameworks como Restlet y Jersey .