CopeLibros4J Arquitectura de la aplicación
CopeLibros:
Arquitectura de la aplicación
La idea principal de la arquitectura tomada es la separación en partes que se encarguen
de diferentes asuntos, y solo se acoplen en puntos específicos (cuando una parte
necesita información de otra o debe indicarle algo).
Parte B Parte C
Parte A
Para nuestra aplicación se decidió, basado en las características de la misma, por tres
grandes partes o paquetes: Dominio, Presentación y Datos.
Cada uno de estos afrontará problemas diferentes:
En el Dominio se implementa la lógica del problema en si, el “negocio”. Este
además se divide en dos subpaquetes:
o Modelo, que corresponde a la modelización de las entidades del problema:
sus estados, sus comportamientos y sus interacciones.
o Servicios, que resuelven las operaciones del usuario, generalmente
estructuradas (a diferencia del comportamiento de las entidades).
En la Presentación se desarrolla interacción con el usuario, en nuestro caso por
medio de páginas Web.
En los Datos es donde se resuelve el acceso a los datos persistentes,
particularmente la base de datos.
por Luis Bersier [http://www.lbersier.com.ar] 1
CopeLibros4J Arquitectura de la aplicación
Evaluando la responsabilidad de los paquetes diseñados, se desprende como es la
interacción entre ellos:
Las entidades del Modelo, al ser una representación del problema real, no deben
depender de cuestiones de infraestructura, y solo se centran en las reglas del
problema.
Los Servicios son las operaciones que realizan los usuarios, y conocen como
ejecutar el Modelo. Además pueden comunicarse con los Datos, para pedir
entidades o guardar cambios en ellas.
La parte de Presentación, como es quien interactúa con el usuario, es la encargada
de ejecutar los Servicios y mostrar los resultados.
El paquete de Datos se encarga de persistir las entidades, para ello conoce el
Modelo y como guardarlo y/o recuperarlo.
PRESENTACION
DOMINIO
SERVICIOS
MODELO
DATOS
por Luis Bersier [http://www.lbersier.com.ar] 2
CopeLibros4J Arquitectura de la aplicación
Yendo más a detalle en la implementación de los paquetes, aparecen conceptos
particulares de cada uno.
Domino: Como se vino hablando, el dominio del problema se modela a partir de las
Entidades, los objetos del problema real que tienen identidad (ejemplo:
usuario, libro, comunidad) y los Servicios que se ofrecen para usar dichos
objetos.
Presentación: La interfaz de usuario de la aplicación es vía Web; las pantallas son
paginas HTML que actúan a modo de Moldes, y hay Manejadores
de paginas, controlados por un objeto Aplicación Web, que
ejecutan los servicios y completan el contenido dinámico.
Datos: Para que se pueda interactuar con los datos persistentes sin depender de la
infraestructura se implementan Repositorios, los cuales pueden recuperar
entidades (de acuerdo a referencias, como IDs), guardar cambios en ellas o
efectuar consultas específicas.
PRESENTACION DOMINIO
Aplicación Web
llama ejecuta Servicio utiliza
Manejador de
pagina Entidad
dispara
pide / envia
envía entidad
contenido
DATOS
INTERFAZ WEB
recupera /
Molde guarda
HTML
accede Repositorio
BASE DE
DATOS
por Luis Bersier [http://www.lbersier.com.ar] 3
CopeLibros4J Arquitectura de la aplicación
Componentes a utilizar:
Para construir el Modelo se utilizara Programación Orientada a Objetos pura; o
sea, las entidades serán POJOs.
Los Servicios se desarrollaran como pares Interfaz / Implementación, evitando
así la dependencia a implementaciones, y quienes los usen solo necesitan
conocer la interfaz.
En la Presentación se utilizará Wicket para implementar el objeto aplicación
(subclase de WebApplication) y los manejadores de pagina (subclases de
WebPage).
Para los Repositorios se utilizaran también pares Interfaz/Implementación, y
en las implementaciones se hará uso de la especificación JPA para el acceso a
base de datos. Como implementación de esta se utilizara Hibernate.
Se implementara el concepto de inyección de dependencia para la creación de
las implementaciones de cada interfaz, siendo así la elección de que clase
instanciar parte de la configuración y no del código. Para aplicar este concepto
se utilizará Spring. También se aprovechará Spring para la configuración de los
frameworks.
por Luis Bersier [http://www.lbersier.com.ar] 4
CopeLibros4J Arquitectura de la aplicación
Implementación
La arquitectura de la aplicación se organiza a través de un contexto, que agrupa los
componentes principales, orquestando su comunicación.
contexto.xml
Servicio
prop: Repositorio
Annotation Manager
Repositorio
Entity Manager
Factory
Vendor
Data Source
TX:Annotation Driven
Transaction Manager
En este contexto tenemos la asignación de Servicios y Repositorios, con su
relación (un servicio tiene como propiedad a un/os repositorio/s).
También el contexto define la configuración de la infraestructura de la aplicación:
o Una fábrica de Entity Manager, interfaz que resuelve la persistencia, con su
implementación y conexión a base de datos.
o Un Transaction Manager, que manejara las transacciones de base de datos
de manera transparente.
o Configuraciones para el uso de Annotations para asignar los Entity Manager
y declarar transacciones.
por Luis Bersier [http://www.lbersier.com.ar] 5
CopeLibros4J Arquitectura de la aplicación
La configuración dada en el contexto de la aplicación, permite la implementación de los
componentes de manera sencilla.
Los Repositorios podrán utilizar los Entity Manager, pidiendo su instanciación a la
fábrica.
RepositorioImpl.java
RepositorioImpl
@PersistenceContext
Entity Manager
Los Servicios, que agregan uno o más Repositorios, podrán declarar transacciones
de manera transparente.
ServicioImpl.java
ServicioImpl
Repositorio
@Transactional
metodo
Por otro lado, en la Presentación, el objeto aplicación (WebApplication), que controla
los manejadores de cada pagina (WebPage), configura el acceso al contexto para
permitir así a las paginas referenciar fácilmente a los Servicios que necesiten.
WebPage.java
WebApplication.java
WebPage
WebApplication
@SpringBean
Spring Servicio
init()
Annotation
por Luis Bersier [http://www.lbersier.com.ar] 6