¿Hay alguna desventaja al vincular mi aplicación con Spring Framework?
No estoy hablando de errores o cuestiones como esa, si las hay. Estoy hablando de cosas estratégicas y arquitectónicas que influirán en el ciclo de vida de mi aplicación.
¿Debo preferir las funciones principales de Spring over Java EE compatibles con el contenedor de EE? ¿Cuáles son las ventajas?
Ya que otras publicaciones aquí mencionan el lado positivo, mencionaré los aspectos negativos de Spring. Incluso con estos aspectos negativos, Spring está omnipresente en su nicho, es confiable y funciona como se anuncia.
Por lo tanto, a los aspectos negativos:
Enorme: no me gustaría poner frascos con 3000 clases en mi pequeño proyecto de pasatiempo.
Hay algunas descripciones de esto como más lentas que algunas otras estructuras DI como Guice o Pico. Anecdótico, y probablemente no demasiado importante.
Tratar algunas partes de la primavera puede ser frustrante cuando no son partes bien documentadas del núcleo y la documentación que encuentra divergen en las múltiples versiones principales.
Como efecto secundario de su tamaño, prepárate para pasar horas alegres repasando montones de clases que, aunque tienen un nombre lógico, comienzan a fusionarse en un montón gigantesco de nombres cuando estás cansado ("seguro, simplemente conectas tu TransactionAwareConnectionFactoryProxy para su UserCredentialsConnectionFactoryAdapter para su .. zzzzzzzz "). Para ser justos, realmente tienen un nombre lógico, es una respuesta razonable al tamaño del marco, pero aún así.
Posiblemente como resultado de esta adaptación de nuevas piezas, la primavera puede ser lenta, al menos para mí. No tanto con Core Spring, pero hay conectores para casi todo, y no están tan bien documentados como podrían estarlo, y ahí es cuando empiezas a vadear la sopa de sustantivos. Nuevamente, todo se debe a su tamaño.
Hay muy pocos inconvenientes en Spring
Pensé largo y tendido para encontrar algún inconveniente serio en el uso de Spring, y me temo que he fallado. Spring es un excelente conjunto de herramientas dentro de los modelos JEE / OSGi. Proporciona una amplia gama de plantillas no invasivas que simplifican enormemente el trabajo con las API de soporte a menudo engorrosas proporcionadas por los contenedores de aplicaciones.
Spring vs the core JEE
Spring no reemplaza las tecnologías JEE principales, bueno, quizás los EJB, pero con la nueva especificación EJB3 casi no contiene nada, en su lugar, proporciona plantillas para facilitar su uso. Considere JAX-RS la API de servicios web RESTful. Spring proporciona el RestTemplate que normalmente se usa de la siguiente manera (se supone que está inyectado):
SomeJaxbAnnotatedClass object = restTemplate.getForObject(someURI,SomeJaxbAnnotatedClass.class);
Esto irá a someURI obtener el XML / JSON / YAML y lo descomprimirá en el objeto de dominio que especifique. Todo en una sola línea de código.
Las excepciones y el registro de errores se manejan como excepciones de tiempo de ejecución, lo que facilita la limpieza del código local. Spring incluso trabaja para reducir las dependencias externas siempre que sea posible, por lo que el ejemplo anterior solo utiliza los paquetes java.net. *).
Hay plantillas para JMS, JAX-WS, JPA, JTA y así sucesivamente. Todos ellos hacen que sea mucho más fácil trabajar con estos estándares y hacer que su código sea más limpio y menos propenso a errores.
Pick'n'mix architecture
Desde un punto de vista arquitectónico, Spring enfatiza un enfoque ligero de pick'n'mix. Esto tiene el efecto de permitir que los arquitectos del sistema eviten el uso de contenedores de aplicaciones inflados para todos, como WebSphere, JBoss o Glassfish, y que elijan a sus homólogos de peso ligero en su lugar: Jetty, Tomcat, etc.
¿Por qué es esto importante? Los contenedores de aplicaciones más grandes tienen un ciclo de actualización mucho más largo que se adapta a las necesidades de algunos clientes más que otros. Los bancos no tienen que ser tan ágiles como una startup de un solo hombre.
Si desea utilizar la última verson de marcos de soporte, es poco probable que los encuentre en los grandes contenedores de aplicaciones. En su lugar, deberá incluirlos manualmente y Spring lo hace fácil.
Además, solo necesita incluir específicamente las tecnologías que necesita. Los contenedores de aplicaciones le darán JMS, EJB y todos los demás acrónimos bajo el sol, pero solo desea una fácil persistencia con JPA. Incluya Spring e Hibernate y listo.
Entonces, ¿por qué no Spring?
Evite Spring si quiere ir con las implementaciones de bibliotecas específicas del proveedor. Además, evítelo si desea mantener sus detalles de configuración dentro de sus clases en lugar de externalizarlos en XML o JNDI. Y definitivamente, evítelo si cree que las soluciones gratuitas y de código abierto no son adecuadas para su entorno.
una cosa interesante que Martin Thompson menciona en este artículo es que la primavera puede tener un impacto no trivial en los tiempos de GC:
Mantenga las pilas de llamadas razonablemente pequeñas. Todavía hay más trabajo por hacer aquí. Si estás lo suficientemente loco como para usar Spring, entonces revisa tus pilas de llamadas para ver a qué me refiero. El recolector de basura tiene que caminar para encontrar objetos accesibles. -Martin Thompson
Este tipo de cosas no será un gran problema para la mayoría de las aplicaciones, pero es una preocupación muy real para el tipo de aplicaciones a las que se refiere Martin.
La primavera es realmente buena. Spring Core está bien. Me gustaría agregar a los otros puntos, si usted está en la categoría de nicho donde el desempeño es realmente una preocupación, querrá evitar los otros módulos Spring, solo si está en manos de los mejores desarrolladores. Esto es solo una preocupación si está ejecutando un sistema donde el rendimiento es realmente crítico. De la mano de los desarrolladores promedio a los buenos, Spring probablemente le dará un impulso de rendimiento al ayudar a escribir código simple y limpio.
La primavera se ha convertido básicamente en parte de la plataforma ahora. En todas partes, en JEE5 y 6, encontrará más y más inyección de recursos, por lo que al menos esa parte de Spring, si se mantiene, es / será solo otra parte de la plataforma, (consulte @Inject). Otras partes ... no estoy tan seguro, especialmente cuando se trata de programación orientada a aspectos. Hay otros proveedores de esos servicios, Guice, originalmente de Google, y Weld, de JBoss, creo que construido en Guice, proporcionará la misma funcionalidad si se adhiere a las especificaciones de inyección de dependencia de Java JSR-330.
YMMV
Spring hace todo lo posible por no ser invasivo en términos de mantenerlo acoplado de manera flexible con el código de su aplicación.
También se está moviendo más en esa dirección a lo largo del tiempo. En versiones anteriores, necesitaría ampliar las clases base, luego se trasladó a las anotaciones, y en la actualidad cada vez se utilizan más los POJO configurados en XML.
Este es un gran beneficio estratégico sobre otros marcos de aplicaciones.