Spring Framework. Contenedor ligero de aplicaciones Introduccion

¿Qué es un framework Java? Es un conjunto de clases e interfaces. El objetivo de los frameworks es facilitar el desarrollo de software. ¿Cómo? Existen multiples naturalezas en los tipos de software, Persistencia de datos, App Web, App Escritorio, Seguridad, Compiladores, Traceo, … En cada “tipo” de software se repite mucha funcionalidad. El framework va a componer una solución abstracta a un problema especifico. Nos permite dedicar el esfuerzo de desarrollo a las peculiaridades del software, y no a las tareas repetitivas de cada naturaleza. Por ejemplo, si vamos a construir una aplicación web de gestión del parte de horas de una empresa, queremos dedicar nuestro esfuerzo al funcionamiento requerido de la aplicación, a la lógica de negocio. No al esfuerzo relacionado con la visualización de datos, entrada y parseo de datos, gestión de usuarios, persistencia en BD

Definiciones de Framework Conjunto de clases que encierra un diseño abstracto para soluciones a una familia de problemas relacionados, soportando la reutilización con una granularidad mayor que las clases. Conjunto de clases que cooperan y forman un diseño reutilizable para un tipo específico de software. Un framework ofrece una guía arquitectónica partiendo el diseño en clases abstractas y definiendo sus responsabilidades y sus colaboraciones. Un desarrollador personaliza el marco de trabajo para una aplicación particular mediante herencia y composición de instancias de las clases del framework.

¿Cómo utilizamos un framework? Herencia de una clase abstracta. Uso de configuración. Uso de interfaces a partir de Factorías. Uso de metainformación (annotations). Conveccion por configuración. Por ejemplo En Struts 1 las peticiones realizadas por cliente, son encapsuladas en clases heredadas de la clase abstracta Action, que nos permite simplificar el manejo de las acciones del cliente obviando la tecnología subyacente, y todo el trabajo extra asociado. Siguiendo con struts, también hace uso de la configuración, que en este caso nos permite crear una indirección entre la acción generada por el cliente, y la clase Heredada de ActionForm que va a manejar esa petición. También establecemos en esta configuración la página a la que se volverá depnediendo del reslutado obtenido. Un ejemplo para el tercer tipo es el Framework de Traceo Log4j, muy usado, en donde nosotros utilizamos una interfaz para el uso del log, que “llenamos” con una Factoría. En este caso también añadimos configuración para especificar el nivel de traza o donde crear los logs, en fichero, en una base de datos, … La “moda” en la construcción de frameworks en la actualidad es el uso de las anotaciones, pues permiten llevar a cabo el uso del framework sin crear una fuerte dependencia. Es información extra añadida a las clases que puede ser accedida en tiempo de ejecución, nos permite trabajar de una forma mas limpia y mantenible, favoreciendo la creación de POJOS Por ejemplo Junit, que en la versión para java 1.4 tenías que realizar herencia de una clase Abstracta para poder gestionar los testeos, pero ahora, en la nueva versión unicamente es necesario El último concepto de convección por configuración es el más moderno y es la base filosófica para otros tipos de lenguajes como Ruby y más concretamente en su framework para desarrollos Web Ruby on Rails. Se basa en minimizar la configuración estableciendo una base de convecciones en el nombrado de los componentes.

Introduccion Es un lightweigth container (JAVA) Pretenden facilitar la cohesión de distintos componentes para formar nuestra aplicación, partiendo del patrón “Inversión del control” IOC. Programación basada en POJO. Manejo del ciclo de vida de los objetos. IOC, inyección de dependencias Consistent configuration Una aplicación es un conjunto de entidades que cooperan de forma COHESIONADA, y no acoplada, un contenedor ligero va a realizar esta cohesión, va a ser el pegamento que permita cooperar a los componentes. -POJO, Plain Old Java Objects, objetos ligeros… -Debido a que va a unir las partes de la aplicación, también van a crear los objetos, y a destruirlos. -IOC, un patrón y es la base para unir los componentes. No nos llames, ya te llamamos nosotros. Es decir, los objetos pierden la responsabilidad de pedir lo que necesitan, unicamente deben realizar su función principial. -La información de unión en Spring se suministra por configuración, y esta ha de ser consistente.

Facilitando Spring pretende facilitar la construcción de aplicaciones, los “facilitadores” Spring es light container, pero no solo eso, ademas es un conjunto de módulos independientes, que nos va a facilitar mucho la tarea de desarrollo, siendo facilitadores o fachadas para el uso de otros frameworks. Y lo van a conseguir estableciendo una capa de abstracción que nos permitirá un uso simplificado de librerias externas o marcos de trabajo. Podemos ver: Core, básicamente el contenedor IOC. AOP, programación orientada a Aspectos. AspectJ. ORM, nos permiten salvar la impedancia entre la OO y las BD relacionales. DAO, JEE, WEB,

AOP Programación Orientada a Aspectos Su objetivo principal es la separación de funcionalidad común en la aplicación. Se basa en el uso de “proxys” que envolverán objetos, controlando todas las llamadas a los métodos. Ejemplo, control de transacciones en la capa DAO. Realmente tenemos un objeto instanciado que va a recibir todas las llamadas al objeto “envuelto” podueddiendo añadir funcionalidad, quitarla o modificarla. Es útil su uso en operaciones que requieren siempre la misma acción, como puede ser realizar consultas a base de datos, siempre hay que iniciar la sesión, iniciar la trnsacción, comitear, cerrar la sesión…

Ejemplo de IOC Interface Hablador { public void habla(String palabras);} class MadrilenioHablador implements Hablador { public void Habla(String palabras) { System.out.println(palabras + “egque"); }} class AndaluzHablador implements Hablador { System.out.println(palabras + “ozu"); class Consumidor{ Hablador hablador = null; public void setHablador(Hablador habl){this.hablador = habl;} public void diAlgo(){hablador.habla(“ mas palabras ”); } Tenemos una interfaz y dos implementaciones. En el consumidor, vamos a ponerle un set a la interfaz, para que el contendor pueda inyectarle la implementación que configuremos.

Ejemplo de IOC <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN""http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id=“hablador" class=“AndaluzHablador“/> <bean id=“consumidor" class=“Consumidor"> <property name="hablador“ ref=“hablador”/> </bean> </beans> Parece algo complejo como el primer hola mundo de java, pero finalmente tenemos un consumidor basado en contrato, en la interfaz, que “llenaremos” con una implementación sin que nadie pida nada, de forma totalmente cohesionada, y con las clases simplificadas. ApplicationContext ac = new FileSystemXmlApplicationContext("context.xml"); Consumer c=(HelloWorld)ac.getBean("consumer"); c.saySomething();

Ejemplos de uso