tag mvc form spring java-ee-6 cdi

form - spring mvc tag select



¿CDI es un buen reemplazo de Spring? (3)

CDI significa "inyección de contexto y dependencia", mientras que Spring es un ecosistema completo alrededor de un contenedor de inyección de dependencia. Para comparar ambos, debe diferenciar la comparación.

La inyección de dependencia es manejada por ambos contenedores. La principal diferencia es el hecho de que CDI maneja DI de forma dinámica (también conocida como "con estado"), esto significa que las dependencias se resuelven en el momento de la ejecución . El enfoque de Spring es estático : esto significa que los componentes están conectados entre sí en el momento de la creación . Mientras que la CDI-way puede parecer un poco inusual a primera vista, es muy superior y ofrece opciones mucho más avanzadas (estoy escribiendo esto con el fondo de dos productivas aplicaciones CDI).

Si nos fijamos en el ecosistema , la situación es diferente: Spring viene con muchos frascos (> 150), mientras que el CDI es bastante pequeño en sí mismo. Un uso típico de CDI sería dentro de un servidor de aplicaciones Java EE 6, pero puede hacer que funcione fácilmente en un motor de servlets o incluso en Java SE. Esto significa que el uso de CDI no supone el uso de Hibernate, JPA, EJB o lo que sea, eso depende de usted.

Si necesita más funcionalidad, CDI viene con el concepto de extensiones portátiles (que por sí mismo hace que la API valga la pena). Existen módulos de extensión independientes como Apache CODI y Seam 3 y cubren temas como seguridad, correo, informes y más.

Para resumir: CDI no es nada como un "reemplazo" para el ecosistema de Spring, es más bien una mejora sobre el mecanismo de inyección de dependencia de Spring. Es parte de Java EE 6, por lo que si está en un GlasFish con Java EE 6, definitivamente debe ir a CDI. En mi opinión, tu pregunta es más bien: ¿Puedo reemplazar Spring con Java EE 6? Supongo que mi respuesta es bastante obvia ;-)

Eche un vistazo a Weld para comenzar bien ...

Estamos planeando escribir una aplicación web desde cero, se ha decidido ir con la última edición de Glassfish que cumple con el estándar Java EE 6, por lo tanto, estamos analizando si se puede usar CDI en lugar de Spring.

¿Podemos decir que CDI podría ser un reemplazo para Spring?


Estoy usando Apache OpenWebBeans como implementación de CDI y MyFaces CODI como extensión portátil para varios proyectos. Estoy muy feliz con eso y no tuve problemas con eso. OpenWebBeans actualmente carece de un poco de vista en cuanto a la documentación, pero si no puede hacer que funcione, es bastante fácil usar los Arquetipos Maven proporcionados por MyFaces para generar proyectos simples con todas las dependencias necesarias o lo puede solicitar en la lista de correo. Es tan bueno si solo trabajas en tu aplicación y no estás bloqueado por errores desagradables. También hice muchos proyectos con Spring. Está bien, pero si preguntas qué usaría para el próximo proyecto, ¡la respuesta clara es OpenWebBeans y CODI! Prefiero OpenWebBeans sobre Weld porque OpenWebBeans es muy adoptable. Es genial porque puedes personalizar más o menos todo lo que no está cubierto por el CDI API / SPI oficial y el runtimeperformance es mejor. Y después del primer proyecto, nunca volvería a preguntar sobre CODI porque es muy estable, tienen lanzamientos regulares y la mayoría de ellos trajeron excelentes características nuevas que mejoran mucho la productividad. CODI es en mi humilde opinión el lugar más estable y de donde provienen la mayoría de las innovaciones en todo el territorio del CDI.

Para responder a su pregunta: Para mí, el CDI reemplazó completamente a Spring, pero necesita extensiones portátiles que llenen los huecos. CDI como estándar nunca tuvo la intención de resolver todo y algunas partes como las conversaciones están rotas por diseño. La buena noticia es que tienes grandes proyectos como MyFaces CODI. CODI soluciona casi todos esos problemas.


Spring es más que solo un contenedor de inyección de dependencia. También tiene herramientas para AOP, plantillas para usar con JPA, SQL, etc. y aún más.

Sin embargo, CDI se puede usar como reemplazo de la DI API de Spring.