Estamos planeando escribir una aplicación web desde cero, se ha decidido incluir 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.¿El CDI es un buen reemplazo de Spring?
¿Podemos decir que CDI podría ser un reemplazo para Spring?
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.
Dependency injection es manejado por ambos contenedores. La diferencia principal es el hecho de que CDI maneja DI en una forma dinámica (también conocida como: con estado), esto significa que las dependencias se resuelven en tiempo de ejecución. El enfoque de Spring es estático - esto significa que los componentes están conectados entre sí al tiempo de creación. Si bien la forma CDI puede parecer un poco inusual en un primer vistazo, es muy superior y ofrece opciones mucho más avanzadas (estoy escribiendo esto con el fondo de dos aplicaciones productivas CDI).
Si nos fijamos en el ecosistema , la situación es diferente: El resorte viene con una gran cantidad de frascos (> 150), mientras que el CDI es bastante pequeña por sí misma. 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 en 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.
En resumen: 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? Creo que mi respuesta es bastante obvia ;-)
Tenga una mirada en Weld a tener un buen comienzo ...
Creo que CDI usa la inyección estática como Spring. De acuerdo con [la documentación de Weld] (http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#injection) 'La anotación @Inject nos permite definir un punto de inyección que se inyecta durante la creación de instancias de frijoles. "Según tengo entendido, la inyección dinámica es una inyección que se produce más de una vez. Ocurre cada vez que se invoca un método comercial en ese componente. También para mí, "inyección de forma de estado" significa la capacidad de manejar la inyección de frijoles de diferentes contextos, utiliza proxies que hacen referencia a la instancia "correcta" de cada frijol –
No, eso no es correcto. No sigo su definición de inyección dinámica. La parte dinámica de CDI es más bien que las dependencias son aproximadas (como su escritura) y que el proxy se ocupará de resolver la dependencia correcta cuando así se solicite (para que dos invocación de una dependencia puedan ser reenviadas a dos instancias diferentes de esa dependencia). Pero tal vez un comentario no es el lugar correcto para iniciar una discusión, es posible que desee abrir una nueva pregunta para eso ... –
¿Sigue siendo así ahora? – naaz
Spring es mucho más que 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 puede utilizarse como reemplazo de la DI API de Spring.
creo CDI maneja el AOP a través de interceptores – prassee
interceptores son muy similares a AOP en general, pero que no tienen la amplitud de las características que proporciona un marco de AOP o un lenguaje como AspectJ. – Behrang
Puede escribir extensiones para agregar interceptores basados en sus reglas a beans. Eso es muy fácil. Para la mayoría de las aplicaciones, los usos extensivos de AOP son demasiado complejos para ser útiles. –
estoy usando como Apache OpenWebBeans aplicación 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 toda la tierra del CDI.
Para responder a su pregunta: Para mí, CDI reemplazó por completo 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.
Véase también https://dzone.com/articles/cdi-10-vs-spring-31-feature – GKislin