Spring es un marco de desarrollo de código abierto para Java empresarial. Las características principales de Spring Framework se pueden usar para desarrollar cualquier aplicación Java, pero existen extensiones para crear aplicaciones web sobre la plataforma Java EE. Spring Framework tiene como objetivo facilitar el uso del desarrollo J2EE y promover las buenas prácticas de programación al permitir un modelo de programación basado en POJO.
A continuación se muestra la lista de algunos de los grandes beneficios de usar Spring Framework:
Lightweight- Spring es ligero en cuanto a tamaño y transparencia. La versión básica de Spring Framework es de alrededor de 2 MB.
Inversion of control (IOC)- El acople suelto se consigue en primavera mediante la técnica de Inversión de Control. Los objetos dan sus dependencias en lugar de crear o buscar objetos dependientes.
Aspect oriented (AOP) Spring admite la programación orientada a Aspect y permite un desarrollo coherente al separar la lógica empresarial de la aplicación de los servicios del sistema.
Container - Spring contiene y administra el ciclo de vida y la configuración de los objetos de la aplicación.
MVC Framework - El marco web de Spring es un marco MVC web bien diseñado, que proporciona una gran alternativa a los marcos web como Struts u otros marcos web menos populares o sobre ingeniería.
Transaction Management Spring proporciona una interfaz de administración de transacciones consistente que puede escalar a una transacción local (usando una sola base de datos, por ejemplo) y escalar a transacciones globales (usando JTA, por ejemplo).
Exception Handling - Spring proporciona una API conveniente para traducir excepciones específicas de tecnología (lanzadas por JDBC, Hibernate o JDO, por ejemplo) en excepciones consistentes y no verificadas.
Los siguientes son los módulos del marco Spring:
- Módulo principal
- Módulo de frijoles
- Módulo de contexto
- Módulo de lenguaje de expresión
- Módulo JDBC
- Módulo ORM
- Módulo OXM
- Módulo de servicio de mensajería Java (JMS)
- Módulo de transacciones
- Módulo web
- Módulo Web-Servlet
- Módulo Web-Struts
- Módulo Web-Portlet
El archivo de configuración de Spring es un archivo XML. Este archivo contiene la información de las clases y describe cómo estas clases se configuran y se introducen entre sí.
La Inversión de Control (IoC) es un concepto general y puede expresarse de muchas formas diferentes y la Inyección de Dependencia es simplemente un ejemplo concreto de Inversión de Control.
Este concepto dice que usted no crea sus objetos, sino que describe cómo deben crearse. No conecta directamente sus componentes y servicios en el código, sino que describe qué servicios son necesarios para qué componentes en un archivo de configuración. Un contenedor (el contenedor IOC) es responsable de conectarlo todo.
Los tipos de IoC son:
Constructor-based dependency injection - La DI basada en constructores se logra cuando el contenedor invoca un constructor de clase con varios argumentos, cada uno de los cuales representa una dependencia de otra clase.
Setter-based dependency injection - La DI basada en Setter se logra mediante el contenedor que llama a los métodos de establecimiento en sus beans después de invocar un constructor sin argumentos o un método de fábrica estático sin argumentos para crear una instancia de su bean.
Dado que puede mezclar DI basado en Constructor y Setter, es una buena regla general usar argumentos de constructor para dependencias obligatorias y establecedores para dependencias opcionales. Tenga en cuenta que el uso de una anotación @Required en un establecedor se puede utilizar para hacer que los establecedores sean dependencias requeridas.
Los principales beneficios de la IOC o la inyección de dependencia son:
Minimiza la cantidad de código en su aplicación.
Hace que su aplicación sea fácil de probar, ya que no requiere ningún mecanismo de búsqueda individual o JNDI en sus casos de prueba unitaria.
El acoplamiento suelto se promueve con un esfuerzo mínimo y un mecanismo menos intrusivo.
Los contenedores IOC admiten la creación de instancias ansiosas y la carga diferida de servicios.
La programación orientada a aspectos, o AOP, es una técnica de programación que permite a los programadores modularizar preocupaciones transversales o comportamientos que atraviesan las divisiones típicas de responsabilidad, como el registro y la gestión de transacciones. La construcción central de AOP es el aspecto, que encapsula los comportamientos que afectan a múltiples clases en módulos reutilizables.
Spring IoC crea los objetos, los conecta, los configura y administra su ciclo de vida completo desde la creación hasta la destrucción. El contenedor Spring usa la inyección de dependencia (DI) para administrar los componentes que componen una aplicación.
Hay dos tipos de contenedores de IoC:
Bean Factory container - Este es el contenedor más simple que proporciona soporte básico para DI. Generalmente, se prefiere BeanFactory cuando los recursos son limitados, como dispositivos móviles o aplicaciones basadas en subprogramas.
Spring ApplicationContext Container - Este contenedor agrega una funcionalidad más específica de la empresa, como la capacidad de resolver mensajes de texto desde un archivo de propiedades y la capacidad de publicar eventos de aplicaciones para los oyentes de eventos interesados.
La implementación de BeanFactory más utilizada es la XmlBeanFactoryclase. Este contenedor lee los metadatos de configuración de un archivo XML y los usa para crear un sistema o una aplicación completamente configurados.
Las tres implementaciones de uso común de 'Contexto de aplicación' son:
FileSystemXmlApplicationContext- Este contenedor carga las definiciones de los beans desde un archivo XML. Aquí debe proporcionar la ruta completa del archivo de configuración del bean XML al constructor.
ClassPathXmlApplicationContext- Este contenedor carga las definiciones de los beans desde un archivo XML. Aquí no es necesario que proporcione la ruta completa del archivo XML, pero debe configurar CLASSPATH correctamente porque este contenedor se verá en el archivo XML de configuración de bean en CLASSPATH.
WebXmlApplicationContext - Este contenedor carga el archivo XML con definiciones de todos los beans desde una aplicación web.
A continuación se muestran algunas de las diferencias:
Los contextos de aplicación proporcionan un medio para resolver mensajes de texto, incluido el soporte para i18n de esos mensajes.
Los contextos de aplicación proporcionan una forma genérica de cargar recursos de archivos, como imágenes.
Los contextos de aplicación pueden publicar eventos en beans que están registrados como oyentes.
Ciertas operaciones en el contenedor o beans en el contenedor, que deben manejarse de manera programática con una fábrica de beans, pueden manejarse declarativamente en un contexto de aplicación.
El contexto de la aplicación implementa MessageSource, una interfaz utilizada para obtener mensajes localizados, con la implementación real que se puede conectar.
Los objetos que forman la columna vertebral de su aplicación y que son administrados por el contenedor Spring IoC se denominan beans. Un bean es un objeto que es instanciado, ensamblado y administrado por un contenedor Spring IoC. Estos beans se crean con los metadatos de configuración que usted proporciona al contenedor, por ejemplo, en forma de definiciones XML <bean />.
La definición de bean contiene la información denominada metadatos de configuración que se necesitan para que el contenedor conozca lo siguiente:
- Cómo crear un frijol
- Detalles del ciclo de vida de Bean
- Dependencias de Bean
Existen los siguientes tres métodos importantes para proporcionar metadatos de configuración al Spring Container:
- Archivo de configuración basado en XML.
- Configuración basada en anotaciones
- Configuración basada en Java
Compruebe el siguiente ejemplo:
<?xml version = "1.0" encoding = "UTF-8"?>
<beans xmlns = "http://www.springframework.org/schema/beans"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id = "helloWorld" class = "com.tutorialspoint.HelloWorld">
<property name = "message" value = "Hello World!"/>
</bean>
</beans>
Al definir un <bean> en Spring, tiene la opción de declarar un alcance para ese bean. Por ejemplo, para obligar a Spring a producir una nueva instancia de bean cada vez que se necesita una, debe declarar que el atributo de alcance del bean esprototype. De manera similar, si desea que Spring devuelva la misma instancia de bean cada vez que se necesita una, debe declarar que el atributo de alcance del bean es singleton.
Spring Framework admite los siguientes cinco ámbitos, tres de los cuales están disponibles solo si usa un ApplicationContext compatible con la web.
singleton - Esto aplica el alcance de la definición de bean a una sola instancia por contenedor Spring IoC.
prototype - Esto permite que una única definición de bean tenga cualquier número de instancias de objeto.
request- Esto aplica una definición de bean a una solicitud HTTP. Solo válido en el contexto de un Spring ApplicationContext compatible con web.
session- Esto aplica el alcance de una definición de bean a una sesión HTTP. Solo válido en el contexto de un Spring ApplicationContext compatible con web.
global-session- Esto aplica el alcance de una definición de bean a una sesión HTTP global. Solo válido en el contexto de un Spring ApplicationContext compatible con web.
El alcance predeterminado de bean es Singleton para el marco Spring.
No, los beans singleton no son seguros para subprocesos en el marco Spring.
A continuación se muestra la secuencia de un ciclo de vida de un frijol en Spring:
Instantiate - Primero, el contenedor de primavera busca la definición del bean en el archivo XML y crea una instancia del bean.
Populate properties - Usando la inyección de dependencia, Spring llena todas las propiedades como se especifica en la definición del bean.
Set Bean Name - Si el bean implementa la interfaz BeanNameAware, Spring pasa la identificación del bean al método setBeanName ().
Set Bean factory - Si Bean implementa la interfaz BeanFactoryAware, Spring pasa el beanfactory al método setBeanFactory ().
Pre Initialization- También llamado posproceso de frijol. Si hay algún bean BeanPostProcessors asociado con el bean, Spring llama al método postProcesserBeforeInitialization ().
Initialize beans- Si el bean implementa IntializingBean, se llama a su método afterPropertySet (). Si el bean tiene una declaración de método init, se llama al método de inicialización especificado.
Post Initialization - Si hay algún BeanPostProcessors asociado con el bean, se llamará a sus métodos postProcessAfterInitialization ().
Ready to use - Ahora el bean está listo para ser utilizado por la aplicación.
Destroy - Si el bean implementa DisposableBean, llamará al método destroy ().
Un elemento <bean /> dentro de los elementos <property /> o <constructor-arg /> define un llamado bean interno. Una definición de bean interno no requiere una identificación o un nombre definidos; el contenedor ignora estos valores. También ignora el indicador de alcance. Los beans internos son siempre anónimos y siempre se consideran prototipos.
Spring ofrece cuatro tipos de elementos de configuración de colección que son los siguientes:
<list> - Esto ayuda en el cableado, es decir, inyecta una lista de valores, permitiendo duplicados.
<set> - Esto ayuda a cablear un conjunto de valores pero sin duplicados.
<map> - Esto se puede utilizar para inyectar una colección de pares nombre-valor donde el nombre y el valor pueden ser de cualquier tipo.
<props> - Esto se puede usar para inyectar una colección de pares de nombre-valor donde el nombre y el valor son cadenas.
El contenedor Spring puede conectar automáticamente las relaciones entre beans colaboradores. Esto significa que es posible permitir que Spring resuelva automáticamente los colaboradores (otros beans) para su bean inspeccionando el contenido de BeanFactory sin usar los elementos <constructor-arg> y <property>.
La funcionalidad de cableado automático tiene cinco modos que se pueden usar para indicar al contenedor Spring que use el cableado automático para la inyección de dependencia:
no- Esta es la configuración predeterminada, lo que significa que no hay cableado automático y debe usar una referencia de bean explícita para el cableado. No tiene nada que hacer en especial para este cableado. Esto es lo que ya ha visto en el capítulo Inyección de dependencias.
byName- Autowiring por nombre de propiedad. El contenedor Spring examina las propiedades de los beans en los que el atributo autowire está establecido en byName en el archivo de configuración XML. Luego intenta hacer coincidir y conectar sus propiedades con los beans definidos por los mismos nombres en el archivo de configuración.
byType- Autowiring por tipo de datos de propiedad. El contenedor Spring examina las propiedades de los beans en los que el atributo autowire está establecido en byType en el archivo de configuración XML. Luego intenta hacer coincidir y conectar una propiedad si su tipo coincide exactamente con uno de los nombres de los beans en el archivo de configuración. Si existe más de uno de esos beans, se lanza una excepción fatal.
constructor- Similar a byType, pero el tipo se aplica a los argumentos del constructor. Si no hay exactamente un bean del tipo de argumento del constructor en el contenedor, se genera un error fatal.
autodetect - Spring primero intenta cablear usando autowire por constructor, si no funciona, Spring intenta autowire por byType.
Las limitaciones del cableado automático son:
Overriding possibility - Aún puede especificar dependencias usando las configuraciones <constructor-arg> y <property> que siempre anularán el cableado automático.
Primitive data types - No puede conectar automáticamente las llamadas propiedades simples como primitivas, cadenas y clases.
Confusing nature - El cableado automático es menos exacto que el cableado explícito, por lo que, si es posible, prefiera utilizar cableado explícito.
Si.
Una alternativa a las configuraciones XML es proporcionada por la configuración basada en anotaciones que se basa en los metadatos del código de bytes para conectar los componentes en lugar de las declaraciones de corchetes angulares. En lugar de utilizar XML para describir el cableado de un bean, el desarrollador mueve la configuración a la clase del componente mediante el uso de anotaciones en la declaración de clase, método o campo relevante.
El cableado de anotación no está activado en el contenedor Spring de forma predeterminada. Entonces, antes de que podamos usar el cableado basado en anotaciones, necesitaremos habilitarlo en nuestro archivo de configuración de Spring configurando <context: annotation-config />.
Esta anotación simplemente indica que la propiedad del bean afectada debe completarse en el momento de la configuración, mediante un valor de propiedad explícito en una definición de bean o mediante el cableado automático. El contenedor lanza BeanInitializationException si la propiedad del bean afectado no se ha poblado.
Esta anotación proporciona un control más detallado sobre dónde y cómo se debe realizar el cableado automático. La anotación @Autowired puede usarse para autowire bean en el método setter al igual que la anotación @Required, el constructor, una propiedad o métodos con nombres arbitrarios y / o múltiples argumentos.
Puede haber una situación en la que cree más de un bean del mismo tipo y desee conectar solo uno de ellos con una propiedad, en tal caso, puede usar la anotación @Qualifier junto con @Autowired para eliminar la confusión especificando qué bean exacto será cableado.
Spring tiene anotaciones basadas en JSR-250 que incluyen anotaciones @PostConstruct, @PreDestroy y @Resource.
@PostConstruct - Esta anotación se puede utilizar como alternativa a la devolución de llamada de inicialización.
@PreDestroy - Esta anotación se puede utilizar como alternativa a la devolución de llamada de destrucción.
@Resource - Esta anotación se puede utilizar en campos o métodos de establecimiento. La anotación @Resource toma un atributo de 'nombre' que se interpretará como el nombre del bean que se inyectará. Puede decir que sigue la semántica de cableado automático por nombre.
La opción de configuración basada en Java le permite escribir la mayor parte de su configuración de Spring sin XML pero con la ayuda de algunas anotaciones basadas en Java.
Por ejemplo: anotación @Configurationindica que el contenedor Spring IoC puede utilizar la clase como fuente de definiciones de beans. los@Bean La anotación le dice a Spring que un método anotado con @Bean devolverá un objeto que debería registrarse como un bean en el contexto de la aplicación Spring.
Manipulación en el Evento ApplicationContext se proporciona a través de la ApplicationEvent clase y ApplicationListener interfaz. Entonces, si un bean implementa ApplicationListener , cada vez que se publica un ApplicationEvent en ApplicationContext, ese bean es notificado.
Spring proporciona los siguientes eventos estándar:
ContextRefreshedEvent- Este evento se publica cuando ApplicationContext se inicializa o se actualiza. Esto también se puede generar usando el método refresh () en la interfaz ConfigurableApplicationContext.
ContextStartedEvent- Este evento se publica cuando se inicia ApplicationContext utilizando el método start () en la interfaz ConfigurableApplicationContext. Puede sondear su base de datos o puede reiniciar / iniciar cualquier aplicación detenida después de recibir este evento.
ContextStoppedEvent- Este evento se publica cuando ApplicationContext se detiene mediante el método stop () en la interfaz ConfigurableApplicationContext. Puede hacer el trabajo de limpieza requerido después de recibir este evento.
ContextClosedEvent- Este evento se publica cuando ApplicationContext se cierra mediante el método close () en la interfaz ConfigurableApplicationContext. Un contexto cerrado llega al final de su vida; no se puede actualizar ni reiniciar.
RequestHandledEvent - Este es un evento específico de la web que le dice a todos los beans que se ha atendido una solicitud HTTP.
Un módulo que tiene un conjunto de API que proporcionan requisitos transversales. Por ejemplo, un módulo de registro se llamaría aspecto AOP para el registro. Una aplicación puede tener varios aspectos según el requisito. En Spring AOP, los aspectos se implementan usando clases regulares (el enfoque basado en esquemas) o clases regulares anotadas con la anotación @Aspect (estilo @AspectJ).
Concern- La preocupación es el comportamiento que queremos tener en un módulo de una aplicación. La preocupación puede definirse como una funcionalidad que queremos implementar. Los temas que nos interesan definen nuestras preocupaciones.
Cross-cutting concern- Es una preocupación que se aplica en toda la aplicación y afecta a toda la aplicación. por ejemplo, el registro, la seguridad y la transferencia de datos son preocupaciones que se necesitan en casi todos los módulos de una aplicación, por lo que son preocupaciones transversales.
Esto representa un punto en su aplicación donde puede incorporar el aspecto AOP. También puede decir que es el lugar real en la aplicación donde se tomará una acción utilizando el marco Spring AOP.
Esta es la acción real que se debe realizar antes o después de la ejecución del método. Este es un fragmento de código real que se invoca durante la ejecución del programa por el marco Spring AOP.
Este es un conjunto de uno o más puntos de unión donde se debe ejecutar un aviso. Puede especificar cortes de puntos usando expresiones o patrones como veremos en nuestros ejemplos de AOP.
Una introducción le permite agregar nuevos métodos o atributos a las clases existentes.
El objeto está aconsejado por uno o más aspectos, este objeto siempre será un objeto proxy. También denominado objeto aconsejado.
Tejer es el proceso de vincular aspectos con otros tipos de aplicaciones u objetos para crear un objeto recomendado.
El tejido se puede realizar en tiempo de compilación, tiempo de carga o en tiempo de ejecución.
Los aspectos de primavera pueden funcionar con cinco tipos de consejos que se mencionan a continuación:
before - Ejecute un consejo antes de la ejecución de un método.
after - Ejecutar un consejo después de la ejecución de un método independientemente de su resultado.
after-returning - Ejecute un consejo después de la ejecución de un método solo si el método se completa correctamente.
after-throwing - Ejecuta un consejo después de la ejecución de un método solo si el método sale al lanzar una excepción.
around - Ejecutar asesoramiento antes y después de invocar el método recomendado.
Los aspectos se implementan usando clases regulares junto con una configuración basada en XML.
@AspectJ se refiere a un estilo de declaración de aspectos como clases regulares de Java anotadas con anotaciones de Java 5.
JDBC se puede usar de manera más eficiente con la ayuda de una clase de plantilla proporcionada por Spring Framework llamada JdbcTemplate.
Con el uso del marco Spring JDBC, la carga de la administración de recursos y el manejo de errores se reduce mucho. Por lo tanto, deja que los desarrolladores escriban las declaraciones y consultas para obtener los datos hacia y desde la base de datos. JdbcTemplate proporciona muchos métodos convenientes para hacer cosas como convertir datos de la base de datos en primitivas u objetos, ejecutar declaraciones preparadas y que se pueden llamar y proporcionar manejo de errores de base de datos personalizado.
Spring admite dos tipos de gestión de transacciones:
Programmatic transaction management- Esto significa que ha gestionado la transacción con la ayuda de la programación. Eso le da una flexibilidad extrema, pero es difícil de mantener.
Declarative transaction management- Esto significa que separa la gestión de transacciones del código comercial. Solo usa anotaciones o configuración basada en XML para administrar las transacciones.
La gestión declarativa de transacciones es preferible a la gestión programática de transacciones, aunque es menos flexible que la gestión programática de transacciones, que le permite controlar las transacciones a través de su código.
El marco Spring web MVC proporciona una arquitectura modelo-vista-controlador y componentes listos que se pueden usar para desarrollar aplicaciones web flexibles y poco acopladas. El patrón MVC da como resultado la separación de los diferentes aspectos de la aplicación (lógica de entrada, lógica empresarial y lógica de la interfaz de usuario), al tiempo que proporciona un acoplamiento flexible entre estos elementos.
El marco Spring Web MVC está diseñado alrededor de un DispatcherServlet que maneja todas las solicitudes y respuestas HTTP.
El WebApplicationContext es una extensión de la llanura Application Context que tiene características necesarias algunas extra para aplicaciones web. Se diferencia de un ApplicationContext normal en que es capaz de resolver temas y sabe con qué servlet está asociado.
A continuación se muestran algunas de las ventajas de Spring MVC sobre Struts MVC:
El MVC de Spring es muy versátil y flexible basado en interfaces, pero Struts fuerza las acciones y el objeto de formulario en una herencia concreta.
Spring proporciona interceptores y controladores, por lo que ayuda a factorizar el comportamiento común para el manejo de muchas solicitudes.
Spring se puede configurar con diferentes tecnologías de vista como Freemarker, JSP, Tiles, Velocity, XLST, etc. y también puede crear su propio mecanismo de vista personalizado implementando la interfaz Spring View.
En Spring, los controladores MVC se pueden configurar usando DI (IOC) que facilita su prueba e integración.
El nivel web de Spring MVC es fácil de probar que el nivel web Struts, debido a que se evita la herencia concreta forzada y la dependencia explícita de los controladores en el servlet del despachador.
Struts obliga a sus controladores a extender una clase Struts, pero Spring no lo hace, hay muchas implementaciones de controladores convenientes que puede elegir extender.
En Struts, las acciones se acoplan a la vista definiendo ActionForwards dentro de un ActionMapping o globalmente. SpringMVC tiene una interfaz HandlerMapping para admitir esta funcionalidad.
Con Struts, la validación generalmente se realiza (implementa) en el método de validación de un ActionForm. En SpringMVC, los validadores son objetos comerciales que NO dependen de la API de Servlet, lo que hace que estos validadores se reutilicen en su lógica comercial antes de conservar un objeto de dominio en una base de datos.
Los controladores brindan acceso al comportamiento de la aplicación que normalmente define a través de una interfaz de servicio. Los controladores interpretan la entrada del usuario y la transforman en un modelo que la vista representa para el usuario. Spring implementa un controlador de una manera muy abstracta, lo que le permite crear una amplia variedad de controladores.
La anotación @Controller indica que una clase en particular cumple la función de controlador. Spring no requiere que extienda ninguna clase base de controlador o haga referencia a la API de Servlet.
La anotación @RequestMapping se usa para mapear una URL a una clase completa o un método de manejo en particular.
Hay dos formas de acceder a la hibernación usando Spring:
Inversión de control con una plantilla de hibernación y devolución de llamada.
Ampliación del soporte de HibernateDAOS y aplicación de un nodo interceptor AOP.
Spring admite los siguientes ORM:
- Hibernate
- iBatis
- JPA (API de persistencia de Java)
- TopLink
- JDO (objetos de datos Java)
- OJB