Spring Parte I

7/24/2019 Spring Parte I

1/20

Captulo I

Introduccin al Spring Framework

1.1.Introduccin.

Spring es un marco de trabajo (framework) open source creado por Rod Johnson basado en

el patrn MVC (Modelo Vista Controlador).

Creado con la finalidad de facilitar la construccin de aplicaciones empresariales, y para ello

Spring hace posible esto con la utilizacin de simples y sencillos Java Beans, lo cual hace

algunos aos atrs era solo posible utilizando EJBs (Enterprise Java Beans).

A continuacin daremos un breve detalle de las caractersticas ms resaltantes de Spring.

Ligero. Spring, es un marco de trabajo ligero en trminos de tamao y memoria. Ladistribucin de Spring puede darse en un simple archivo jar de t amao aproximado

de 2.5 mb.

No intrusivo. Las aplicaciones desarrolladas en Spring no contienen dependencias

hacia clases del marco de trabajo, lo que permite mantener la independencia de las

mismas.

Inyeccin de dependencias. Spring promueve el desacoplamiento entre clases

conocido como Inyeccin de dependencias.

Contenedor. Spring es un contenedor dado que se encarga del ciclo de vida y

configuracin de los objetos utilizados por las aplicaciones.

1.2.Mdulos Spring.

El marco de trabajo Spring est compuesto por una variedad de mdulos que otorgan a los

desarrolladores los medios para desarrollar aplicaciones empresariales de acuerdo a sus

necesidades. Es importante dejar en claro que no todos los mdulos pueden ser utilizados, el

desarrollador es libre de elegir que mdulos utilizar para su aplicacin.

En la siguiente figura podemos observar los mdulos que componen el marco de trabajo

Spring.


2/20

Figura. 1. Mdulos Spring

A continuacin detallamos los mdulos que conforman el marco de trabajo:

Core Container. Provee la funcionalidad fundamental del marco de trabajo. Contiene

la factora de Beans (BeanFactory), que representa al contenedor Spring y la base de la

inyeccin de dependencias.

Spring AOP. Provee el soporte para la programacin orientada a aspectos. De manera

similar a la inyeccin de dependencias, el mdulo permite el desacoplamiento de los

objetos java.

DAO (Data Access Objects Module). Este mdulo abstrae al programador de la

interaccin con los gestores de bases de datos.

ORM (Object Relational Module). Provee el soporte a diversos marcos ORM como JPA,

Hibernate, Ibatis, etc.

JEE. Provee el soporte a componentes empresariales como EJBs, Mensajera JMS, etc.

Web. Ofrece el soporte para la construccin de aplicaciones basadas en el patrn

MVC.

1.3.Arquitectura de una aplicacin Spring.

A continuacin observaremos cmo una tpica aplicacin Spring es organizada.

Spring est diseado para facilitar la flexibilida de la arquitectura de una aplicacin. Por

ejemplo, si desea pasar de Hibernate a Ibatis viceversa usando Spring debera ser una tarea


3/20

simple; de la misma manera si deseamos intercambiar algn otro componente de nuestra

aplicacin.

Capa de Presentacin

JSPs u otras vistasHTML

Generado.

Acciones de la capa web

(Web Tier). Se procesan

acciones de los usuarios, se

realizadan llamadas a la

capa de servicios, se

selecciona la vista a

desplegar.

Capa de negocios / servicios. Expone la

funcionalidad clave de la aplicacin. Gestiona

transacciones. Lgica de negocios. No conoce de

implementaciones de persistencia.

Interface DAO. Define las operaciones de

persistencia independientemente de la tecnologa

a implementar.

Implementacin DAO. Recupera, almacena

entidades utilizando herramientas ORM JDBC.

RDBMS

Capa de mapeo O/R

Objetos del

dominio

(Entity).

Persistentes.

J

D

B

C

Servicios remotos: web services u

otros protocolos


4/20

Lo resumimos de la siguiente manera:

Capa de presentacin. Lo ms delgada posible, dado que debe ser posible alternar

distintas capas de presentacin, cmo las capa web capa de servicios remotos.

Capa de Negocios / Servicios. Responsable de las transacciones del sistema.Esta capa

no debera tener conocimiento sobre la capa de presentacin y debera ser lo ms

reutilizable posible.

Interface DAO. No contiene lgica de negocios. Representa las interfaces

(independientes de cualquier tecnologa de acceso a datos). La implementacin de

estas interfaces normalmente usan cualquier tecnologa O/R JDBC.

Objetos del dominio. Objetos persistentes que forman parte del modelo de datos.

Bases de datos. Repositorios de informacin.

1.4.Inversin de Control / Inyeccin de Dependencias.

El objetivo la idea bsica del diseo es seccionar el sistema en un grupo de objetos

reutilizables. Sin un mdulo central para la gestin de objetos, los mismos tendrn que crear y

gestionar sus propias dependencias. Como resultado: objetos altamente acoplados.

La solucin para este caso pasa por la necesidad de poseer un contener encargado de

gestionar los objetos utilizados por el sistema e inyectarlos a quien los necesite.

Antes de proceder a analizar como contenedores como Spring utilizan esta caracterstica tan

importante, analicemos como separar las interfaces de la implementacin.

Supongamos que hemos desarrollado un nuevo sistema en el cual una de sus funcionalidades

es la generacin de diversos tipos de reportes tales como HTML PDF. Lo ideal es crear una

una interface que contenga lo siguiente:

public interface ReportGenerator {

public void generate(String [][] table);

}

Fig. 2. Interface ReportGenerator

A continuacin observaremos las clases que implementaran la interface en mencin para la

generacin de los reportes en los formatos ya mencionados.


5/20

public class HtmlReportGenerator implements ReportGenerator{

public void generate (String[][] table) {

System.out.println(Generating HTML report .);

}}

Figura 3. Clase HtmlReportGenerator.

public class PdfReportGenerator implements ReportGenerator{

public void generate (String[][] table) {

System.out.println(Generating PDF report .);

}

}

Figura 4. Clase PdfReportGenerator.

Ahora observemos la siguiente clase:

public class ReportService {

prvate ReportGenerator reportGenerator = new PdfReportGenerator();

public void generateAnnualReport (int year) {

String[][] statistics = null;

// Obteniendo las estadsticas del ao.

reportGenerator.generate(statistics);

}

public void generateMonthlyReport (int year, int month) {

String[][] statistics = null;

.. // obteniendo las estadsticas

reportGenerator.generate(statistics);

}

}

Fig. 4. Clase ReportService.

Analizando la clase ReportService, La lgica de negocio est claramente representada por esta

clase, por lo tanto, el formato de salida de los reportes depender cual clase ReportGenerator

sea implementada.


6/20

Como complemento podemos observar el siguiente diagrama de clases que muestra la

relacin entre las clases ya mencionadas.

+ generateAnnualReport()+ generateMonthlyReport()

ReportService

+ generate()

ReportGenerator

(Interface)

+ generate()

HtmlReportGenerator

+ generate()

PdfReportGenerator

Fig. 5. Diagrama de clases.

Analizando el diagrama de clases anterior, observamos que ReportService es el responsable de

crear la instancia de tipo ReportGenerator, la cual puede ser HtmlReportGenerator

PdfReportGenerator, causando una dependencia directa an entre ReportService y las clases

mencionadas.

Ahora por un momento imaginemos que tenemos un contenedor como Spring encargado de

gestionar el ciclo de vida de nuestros objetos, y que la clase ReportService no tiene porque ser

la reponsable de instanciar a las otras clases, sino que las mismas son inyectadas por el

contenedor hacia la clase ReportService, por lo tanto observaremos una grfica como la que

sigue:

+ generateAnnualReport()

+ generateMonthlyReport()

ReportService

+ generate()

ReportGenerator

(Interface)Inyectada

Puede ser tanto una

implementacin de

HtmlReportGenerator

PdfReportGenerator

Fig. 6. Inyeccin de dependencias.

La figura anterior se puede observar que la clase ReportService no debe realizar ms la

instancia de alguna clase, sino que las mismas son inyectadas por el Contenedor que en

nuestro caso estar representado por Spring.

El principal beneficio de la inyeccin de dependencias, es el bajo acoplamiento entre clases. Si

un objeto slo conoce a sus dependencias a travs de sus interfaces entonces las

dependencias pueden ser cambiadas en cualquier momento sin traer como consecuencia

cambios drsticos en la aplicacin.


7/20

Captulo II

Core Spring

El corazn de Spring est representado por un contenedor ligero responsable de gestionarque implementa las funcionalidades ligadas a Inversin de Control e Inyeccin de

Dependencias.

En la actualidad Spring trae consiguo diversas implementaciones del contenedor de Beans que

pueden ser categorizadas en dos tipos: La ms bsica conocida como BeanFactory y la

segunda conocida como ApplicationContext construda sobre la base de la anterior y con un

conjunto mayor de funcionalidades.

Trabajar con la implementacin BeanFactory resulta ideal para aplicaciones simples, pero si

deseamos aprovechar todo el poder del marco de trabajo Spring, tendramos que evaluar elsegundo tipo de contenedor.

2.1. Ciclo de vida de los Beans.

En una aplicacin java tradicional, el ciclo de vida de un bean es bastante simple; slo basta

usar la instruccin new y est listo para ser usado. Una vez que el Bean no se encuentre

siendo usado, el mismo es elegible por el recolector de basura para su respectiva destruccin.

El ciclo de vida de los Beans gestionados por un Contenedor como Spring es mucho ms

elaborado, observemos la siguiente figura:

Fig. 7. Ciclo de vida de los BeansSpring.


8/20

Detallamos a continuacin la imagen anterior:

Instantiate. Los beans son instanciados utilizando su(s) constructor(es).

Populate Properties. Spring inyecta valores a las propiedades de los beans.

Set bean name. Si el Bean implementa la interface BeanNameAware, Spring enva el ID

del Bean al mtodo setBeanName().

Set bean factory. Si el Bean implementa la interface BeanFactoryAware, Spring enva la

factora de beans al mtodo setBeanFactory().

Postprocess. Si existe algn BeanPostProcessor, Spring ejecuta el mtodo

postProcessBeforeInitialization().

Initialize beans. Si el Bean implementa la interface InitializingBean, Spring ejecuta el

mtodo afterPropertiesSet().

PostProcess. Si existe algn BeanPostProcessor, Spring ejecuta el mtodo

postProcessAfterInitialization().

Bean is ready to use. En este punto, el bean est listo para ser usado por la aplicacin,

y permanecer en la factora hasta que no sea ms necesitado.

Destroy bean. Si el Bean implementa la interface DisposableBean, el mtodo destroy()

es ejecutado

2.2.Creando Beans.

Empecemos creando un simple bean basndonos en el ejemplo del captulo anterior. Para ello

creamos una nueva versin de la interface ReportGenerator y las dos clases que la

implementan HtmlReportGenerator y PdfReportGenerator.

Por lo tanto nuestro cdigo quedar de la siguiente manera.


9/20

Fig. 8. Interface ReportGenerator.

A continuacin las clases que implementan la interface.

Fig. 9. Clase HtmlReportGenerator


10/20

Fig. 10. Clase PdfReportGenerator

Una vez creadas nuestras clases, podemos proceder a registrarlas dentro del contenedor

Spring, para ello utilizamos el fichero applicationContext.xml (es opcional utilizar otro

nombre).

Fig. 11. applicationContext.xml

En la figura anterior podemos observar que el contenedor Spring crear una instancia de laclase HtmlReportGenerator. Ahora observemos nuestra aplicacin:


11/20

Fig. 12. Clase Main

De la grfica anterior observamos que la aplicacin no conoce que tipo de ReportGenerator

ser utilizado ya que es responsabilidad del contenedor Spring.

La salida de la aplicacin se puede observar en la siguiente figura:

Fig. 13. Salida de la aplicacin.


12/20


13/20

Fig. 16. applicationContext.xml

Fig. 17. Clase Main.

2.3.2. Inyectando referencias de objetos a travs de constructores.

Tal como hemos visto en los ejemplos anteriores, en Spring tambin es posible pasar

argumentos a los constructores que representan referencias a otros objetos.

Observemos la clase Report, la cual define los siguientes atributos con sus respectivosmtodos set / get.


14/20

Fig. 18. Clase Report

A continuacin observamos la clase HtmlReportGenerator que procede a imprimir el cuerpo

de la clase Report, pero previamente la misma es enviada como referencia.


Ahora observemos la inicializacin de ambas en el fichero de configuracin

applicationContext.xml.


15/20

Fig. 20. applicationContext

2.3.3. Inyectando en los atributos del bean.

Un bean java normalmente define mtodos set / get para cada atributo definido. Spring puede

tomar ventaja de esto utilizando los mtodos set, con la finalidad de insertar valores en los

atributos de los beans. Modifiquemos la clase Report de la siguiente manera:

Fig. 21. Clase Report.


16/20


2.3.4. Inicializando colecciones.

Los elementos y son los elementos ms utilizados en Spring que permiten

almacenar un conjunto de valores determinado. El uso de estos elementos se puede observar

en la siguiente figura:



17/20

Fig. 24. applicationContext.

2.3.5. Autowiring.

Anteriormente hemos visto como Spring puede instanciar e inyectar las dependencias a travs

de elementos como . Asimismo, es factible indicarle a Spring

que defina automticamente el objeto a instanciar y enviar.

En la actualidad existen 4 tipos de autowiring.

byName. Spring ubica el bean cuyo nombre ID sea exactamente el mismo que el de

la propiedad a la cual se le pasar la dependencia.

byType. Spring ubica el bean cuyo tipo coincida con el tipo de propiedad a la cual se le

pasar la dependencia. En caso que existan ms de una coincidencia, se lanzar una

excepcin (UnsatisfiedDependencyException).

Constructor. Spring intenta ubicar uno ms beans en el contenedor con los

parmetros de uno de los constructores del bean que est siendo declarado.

Autodetect. Elige entre autowiring byType constructor.


18/20

A continuacin observamos la siguiente figura:


En la figura anterior observamos la declaracin de un cuyos elementos hacen referencia

a las dos instancias de reports (report1 y report2). Posteriormente al declarar

HtmlReportGenerator con un autowire byName, nos damos cuenta que al existir una

propiedad denominada reports en esta clase y coincidir este nombre con la lista declarada

anteriormente, la misma es inyectada a dicha propiedad.

A continuacin observemos la siguiente imagen, en ella visualizaremos un ejemplo donde el

autowiring es del tipo byType, similar al ejemplo anterior slo que en este caso Spring busca

las coincidencias por tipo de datos.


19/20

Fig. 26. applicactionContext.

A continuacin observaremos un ejemplo con el tercer tipo de autowiring.


En la figura anterior, observamos que la clase report_generator tiene un autowire de tipo

constructor, lo que significa que al tener esta clase un constructor con un parmetro de


20/20

entrada de tipo String, Spring busca y encuentra que el bean annio declarado es del

mismo tipo por lo tanto lo transfiere hacia el constructor del bean.

2.4.Alcance de los Beans.

Por defecto todos los beans declarados en Spring son singletons, esto quiere decir quesiempre el contenedor Spring devuelve la misma instancia del bean. En ocasiones, existen

momentos en que esta forma de gestionar instancias no es la ms apropiada, sino que es

necesario que el contenedor devuelva una instancia por cada llamada, por lo que deberamos

decirle utilizar el atributo al momento de declarar el bean y establecerlo en

prototype.

En la siguiente tabla encontraremos los tipos de permitidos en Spring.

Scope Descripcin

Singleton Una sola instancia del bean por contenedor. (Por defecto).

Prototype El bean puede ser instanciado varias veces; una por cada usoque se le d.

Request La instancia existe como parte de un request. Vlido solo

para Spring MVC.

Session La instancia forma parte de una sesin HTTP. Vlido solo

para Spring MVC.

Global-session La instancia forma parte de una sesin global HTTP. Vlido

slo para Portlets.

Spring Parte I

Documents

Transcript of Spring Parte I