patrones de diseño empresariales - principalcs.uns.edu.ar/~atrellini/ayds/downloads/clases/14. ayds...

23/05/2015

1

Lic. Ariel Trellini

Departamento de Ciencias e Ingeniería de la ComputaciónUniversidad Nacional del Sur

Arquitectura y Diseño de Sistemas • 2 Lic. Ariel Trellini • DCIC • UNS

Patrones de Diseño Empresariales

Llamando las cosas con un nombre


Bibliografía


Martin Fowlerwww.martinfowler.com

Patterns of Enterprise Application Architecture (2002)


¿Qué son los Patrones de Diseño?


¿Alguno puede esbozar una definición de patrón de diseño?

Cada patrón describe un problema que ocurre una y otra vez en

nuestro ambiente, y luego describe el núcleo de la solución a

aquel problema, de forma tal que dicha solución pueda utilizarse

un millón de veces más, sin hacer exactamente lo mismo dos

veces.

Christopher Alexander


Tener en cuenta el contexto El punto clave de esta definición es que un patrón define el núcleo de la

solución de un problema y no la solución exacta a aplicar.

Nunca se puede aplicar a ciegas la solución provista por un patrón de diseño, siempre es necesario considerar el contexto del problema.

Conocerlos, aunque no en detalle

Patrones de Diseño Empresariales ¿Qué son los Patrones de Diseño?

CONOCIMIENTO

Requerido Opcional

Qué patrones existen Los detalles de la solución

Qué problemas resuelven Las variantes posibles

Una idea de la manera en que resuelven el problema


Independencia relativa Cada patrón es relativamente independiente, pero no están aislados unos

de otros.

Ejemplo:

Class Table Inheritance Domain Model

Auto-definición Los límites entre patrones muchas veces son muy difusos, pero se intenta

que sean tan auto-definidos como se pueda.

Ayuda en la comunicación Para desarrolladores experimentados, el valor de un patrón de diseño no

está en obtener una nueva idea, sino en ayudar a comunicar la idea.

Patrones de Diseño Empresariales ¿Qué son los Patrones de Diseño?

23/05/2015

2


Aplicaciones Empresariales

Patrones de Diseño Empresariales Aplicaciones Empresariales

Aplicaciones Empresariales Aplicaciones No Empresariales

Sistema de sueldos Inyección de combustible en autos

Administración de pacientes Procesadores de texto

Seguimientos postales Controladores de ascensores

Seguros Controladores de planta

Banca electrónica Switches telefónicos

Sistemas contables Sistemas operativos

Stock Compiladores

Venta electrónica Juegos

Retail


Caracterísiticas

Datos Persistentes: La información persistida generalmente es el núcleo del sistema y su ciclo de vida es más amplio que el del resto de los componentes.

Gran Cantidad de Datos: Un sistema moderado contará con alrededor de 1GB de datos, organizados en decenas de millones de registros, siendo esta información la mayor parte del sistema.

Acceso Concurrente a Datos: Generalmente muchas personas acceden a los datos concurrentemente. Debido a esto, hay problemas bien determinados que deben abordarse para asegurar que los distintos usuarios pueden acceder a la información de manera confiable.



Caracterísiticas (cont.)

Gran Cantidad de UI: Para manejar tanta información es necesario disponer de cientos de pantallas que permitan presentar los datos de distinta forma y, eventualmente, para distintas audiencias.

Integrado con Otras Aplicaciones Empresariales: Las aplicaciones empresariales raramente viven de manera aislada; generalmente requieren integrarse con otras aplicaciones de la empresa o fuera de la misma

Lógica de Negocio Compleja: Las reglas de negocio nos caen encima y por más que intentemos darle integridad lógica, no se puede hacer mucho. Unas pocos miles de estos casos extraordinarios es lo que conduce a una “compleja ilógica de negocio” que hace que el sw de negocios sea tan complejo.



Separación en Capas Básica

Patrones de Diseño Empresariales Layering

• Interpretar los comandos del usuario y mostrar información al usuario. Presentación

• Tareas que la aplicación necesita realizar para cumplir con los requerimientos del negocio que resuelve la aplicación.

Dominio

• Comunicarse con otros sistemas que realizan tareas por medio de la aplicación.

Acceso a Datos

Layering a Considerar


Disposición de las Capas

¿Cómo implemento una capa?

Patrones de Diseño Empresariales Layering

Presentación

Dominio

Acceso a Datos

Opción 1

Presentación

Dominio

Acceso a Datos

Opción 2

Métodos

Clases

Componentes

Layering Depende de la complejidad de la aplicación


Organizando la Lógica de Dominio

Transaction Script

Domain Model

Table Module

Service Layer


Presentación

Dominio

Acceso a Datos

23/05/2015

3


Transaction Script

Patrones de Diseño Empresariales Organizando la Lógica de Dominio

Organiza la lógica de negocio por procedimiento, donde cada

procedimiento maneja un único request desde la capa de

presentación.

Presentación

Dominio

Acceso a Datos

Pre

sen

taci

ón

Acc

eso

a D

ato

s

Dominio

Reservar Aula

Inscribir Alumno

Calcular Promedio

Asignar Nota

Programar Clase

Un Transaction Script organiza cada una de estas transacciones de negocio (funcionalidades) en un único procedimiento, haciendo las llamadas pertinentes a la capa de acceso a datos. Cada transacción de negocio tendrá su propio TransactionScript, aunque sub-tareas comunes pueden ser aisladas en sub-procedimientos.


¿Cómo Trabaja? Un Transaction Script se podría resumir en validar los datos de entrada,

consultar la bd, realizar cálculos y guardar los resultados en la bd.

Patrones de Diseño Empresariales Organizando la Lógica de Dominio Transaction Script

Presentación

Dominio

Acceso a Datos


¿Dónde poner los Transaction Scripts?

Recomendación

Separar los Transaction Script tanto como podamos.

No realizar ninguna llamada desde un Transaction Script a lógica de Presentación.

Poner los Transaction Scripts en clases de una de la siguiente forma:

Tener varios TS en una única clase, donde cada clase define un área sujeto de TS relacionados. Esto es directo y la más apropiada en muchos casos. Ejemplo: NotasService, ClasesService, etc.

Tener cada TS en su propia clase utilizando el patrón Command (GoF)


Una server page

Un script CGI

Un método

Una clase

Un conjunto de clases

Presentación

Dominio

Acceso a Datos


¿Cuándo utilizarlo? Dada su simplicidad, es natural utilizarlo en aplicaciones que tenga poca

lógica de negocios, ya que involucra poco overhead tanto en performance como en curva de aprendizaje.

A medida que la lógica de negocio se torna más compleja, es difícil mantenerlo con un buen diseño.

Generalmente se tiene problemas con la duplicación de código. Puesto que el foco está en resolver una transacción, muchas veces se tiende a duplicar código común.


Presentación

Dominio

Acceso a Datos


Domain Model


Un modelo de objetos del dominio que incorpora tanto

comportamiento como datos.

Presentación

Dominio

Acceso a Datos

Un Domain Model crea una red de objetos interconectados, donde cada objeto representa a un concepto significativo, ya sea tan grande como una corporación o tan pequeño como un ítem de una factura.

Pre

sen

taci

ón

Acc

eso

a D

ato

s

Dominio

Aula

Alumno

InscripcionMateria

Nota

ClaseCarrera

Profesor


¿Cómo Trabaja?

Patrones de Diseño Empresariales Organizando la Lógica de Dominio Domain Model

Presentación

Dominio

Acceso a Datos

Data Objects

Business Rules

DomainModel

Insertar una capa entera de objetos que modelen el negocio

Muchas veces utilizamos 2 tipos de objetos para la capa de negocios: objetos que representan los datos y objetos que capturan las reglas que el negocio utiliza. Con este patrón se combinan estos dos tipos de objetos para poner los procesos de negocio cerca de los datos con los que trabaja.

23/05/2015

4


Ejemplo


Presentación

Dominio

Acceso a Datos


Diferencias entre un Domain Model y un Database Model DM mezcla datos y procesos

DM tiene atributos multivaluados

DM tiene una compleja red de asociaciones

DM usa herencia

Tipos de Domain Model Simples: Lucen muy parecidos al modelo de base de datos, normalmente

con un objeto de dominio por cada tabla de la base de datos. Puede utilizar el patrón Active Record para el acceso a datos.

Ricos: Puede lucir diferente al modelo de base de datos, incorporando herencia, strategies, otros patrones de diseño orientados a objetos [GoF] y redes complejas de pequeños objetos interconectados. Requiere utilizar el patrón Data Mapper para el acceso a datos.


Presentación

Dominio

Acceso a Datos


¿Cuándo utilizarlo?Existen varios factores que pueden determinar el uso o no de un Domain Model:

Complejidad de comportamiento del sistema

Si tenemos reglas de negocio complicadas y cambiantes que involucran validaciones, cálculos, etc, sería preferida la utilización de un Domain Model. En cambio, si solamente se tienen chequeos de campos requeridos y un par de sumas para realizar, probablemente sea suficiente con Transaction Script.

Comodidad del equipo en el uso de objetos de domino

Aprender a diseñar y usar un Domain Model es un ejercicio significativo. Principalmente lleva práctica y coaching, pero una vez que se utiliza correctamente poca gente quiere volver a un Transaction Script para situaciones que no sean demasiado simples.

Posibilidad de utilizar un Data Mapper para el acceso a datos

En algunas circunstancias, no es posible o lleva mucho esfuerzo utilizar un Data Mapper y esto complica la utilización de Domain Model.


Presentación

Dominio

Acceso a Datos


Table Module


Una única instancia que maneja la lógica de dominio para todas

las filas en una tabla o vista de la base de datos.

Presentación

Dominio

Acceso a Datos

Un Table Module organiza la lógica de dominio con una clase por tabla de base de datos, y una única instancia de una clase contiene los distintos procedimientos que actuarán sobre los datos. Así se logra también agrupar los datos con el comportamiento que los utiliza.

Pre

sen

taci

ón

Acc

eso

a D

ato

s

Dominio

Aulas

Alumnos

InscripcionesMateria

Notas

ClasesInscripciones

Profesores


¿Cómo Trabaja?A simple vista Table Module se parece a un objeto regular. Sin embargo, veamos

algunas características que ilustran su funcionamiento con más detalle.

Sin identidad Table Module no tiene noción de identidad de los objetos con los que

trabaja.

Ejemplo: Obtener el nombre de un alumno.

string alumnosModule.ObtenerNombre(long alumnoID)

Patrones de Diseño Empresariales Organizando la Lógica de Dominio Table Module

Si tenemos muchos alumnos, Domain Model tendrá un objeto Alumno por

cada alumno; mientras que Table Module tendrá un objeto que maneje

todos los alumnos.

Entonces… ¿en qué se diferencian Table Module con Domain Model?

Presentación

Dominio

Acceso a Datos


Estructura de datos de respaldo Generalmente se usa un Table Module con una estructura de

datos de respaldo que sea orientada a tablas.

Normalmente estos datos tabulares resultan de una consulta SQL y se mantiene en un Record Set que imita a la tabla en la base de datos.

La forma de uso más común es tener una Table Module por cada tabla en la base de datos. Sin embargo, si se presentan vistas o consultas de base de datos relevantes, se puede tener un Table Module para ellas también.

Implementación Colección de métodos estáticos: Poco usada ya que siempre trabajaría

sobre la tabla entera.

Instancia:

Permite inicializar el Table Module con un record set existente (probablemente el resultado de una consulta)

Permite el uso de herencia: Se podría construir un Table Module AlumnoPosgrado que contenga comportamiento adicional al alumno regular.


Presentación

Dominio

Acceso a Datos

23/05/2015

5



Interacción típica de las capas alrededor de un Table Module

Presentación

Dominio

Acceso a Datos


Ejemplo

Patrones de Diseño Empresariales Organizando la Lógica de Dominio Table Module Presentación

Dominio

Acceso a Datos


¿Cuándo utilizarlo?

Las recomendaciones ante distintos escenarios, podrían ser:

Dado que está basado en la manipulación de datos orientados a tablas, cobra mayor sentido utilizarlo cuando se está accediendo a datos tabulares usando Record Set.

Trabaja mejor que Domain Model + Active Record cuando otras partes de la aplicación están basadas en una estructura de datos orientada a tablas.


Presentación

Dominio

Acceso a Datos

Facilidad para manejar lógica compleja

Facilidad de integración con estructuras de datos orientadas a tablasD

om

ain

Mo

del

Table

Mo

du

le


En casos de alta complejidad de lógica de negocios, Domain Model es una mejor opción. Con Table Module se pierde el poder de la orientación a objetos en organizar lógica compleja: no se pueden tener relaciones entre instancias, ni polimorfismo.


Presentación

Dominio

Acceso a Datos


Service Layer


Define el límite de una aplicación con una capa de servicios que

establecen el conjunto disponible de operaciones y coordina la

respuesta de la aplicación en cada operación.

Presentación

Dominio

Acceso a Datos

UI

Acc

eso

a D

ato

s

Dominio

Serv

ice

Laye

r

DomainLogic

Otros Sistemas

BPMs


Patrones de Diseño Empresariales Organizando la Lógica de Dominio Service Layer

Razones de ejemplo para proveer una Service Layer :

Proveer una API sobre la lógica de negocio que puede ser consumida desde

distintos clientes: UI, otras aplicaciones, BPMs, etc.

Manejar transacciones a través de múltiples recursos (por ej, Tx

Distribuidas) y coordinar distintas respuestas para una operación

(workflows, lógica de interacción con otros sistemas).

Presentación

Dominio

Acceso a Datos

23/05/2015

6


¿Qué se resuelve en la Service Layer? Lógica de Aplicación

Está relacionada a responsabilidades de la aplicación (envío de notificaciones, integración con otras aplicaciones, etc). También se la conoce como “lógica de workflow”. Éste es el tipo de lógica involucrado en una Service Layer.

¿Dónde poner la Lógica de Aplicación? Service Layer factoriza la lógica de aplicación en una capa separada,

promoviendo los beneficios conocidos de layering y produciendo clases de negocio puras y más reusables de aplicación en aplicación.

Desventajas de poner lógica de aplicación dentro de las clases de la lógica de dominio:

Las clases de domino son menos reutilizables entre aplicaciones

Mezclar ambos tipos de lógica en una misma clase hace más difícil reimplementar la lógica de aplicación en, por ej., una herramienta de workflows.


Presentación

Dominio

Acceso a Datos


Remoto o No

Costo:

Tratar con distribución de objetos

Trabajo extra con Data Transfer Objects (DTOs)

Consejos

Comenzar con una Service Layer invocable localmente, cuyos métodos hablen en términos de los objetos del dominio.

Hacerla remota si fuera necesario, poniendo Remote Facades sobre la ServiceLayer, o haciendo que la Service Layer implemente interfaces remotas.

Si la aplicación tiene una Capa de Presentación web, no hay ninguna ley que diga que la lógica de negocio tiene que correr en un proceso separado. Por el contrario, se puede ahorrar esfuerzo de desarrollo y tiempo de respuesta sin sacrificar escalabilidad con una aproximación local.


Presentación

Dominio

Acceso a Datos

ServiceLayer

CoarseGrained

Invocación Remota


Identificación de Servicios y Operaciones Las operaciones necesarias en una Service Layer están determinadas por las

necesidades de los clientes de dicha Service Layer (generalmente la UI)

Basarse en:

Modelo de casos de uso

Pantallas

Necesidades de interacción con otros sistemas

¿Cuándo utilizarlo? Más de un tipo de cliente sobre la lógica de negocio

Se haga uso de múltiples recursos transaccionales

Un único tipo de cliente (generalmente la UI).

Se trabaja con una única base de datos.


Presentación

Dominio

Acceso a Datos


Mapeando a Bases de Datos Relacionales


Presentación

Dominio

Acceso a Datos

¿Cómo se puede resolver el desajuste entre modelo de objetos y modelo relacional?

Existen distintos tipos de patrones que consideran la problemática de la persistencia de datos:

Patrones Arquitectónicos

Patrones de Comportamiento Objeto-Relacional

Patrones Estructurales Objeto-Relacional

Patrones de Mapeo de Metadatos Objeto-Relacional


Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales

Tipo de Patrón Objetivo Patrones

Patrones Arquitectónicos

¿Cómo la lógica de dominio se comunica con la base de datos?

Table Data GatewayRow Data GatewayActive RecordData Mapper

Patrones de Comportamiento Objeto-Relacional

¿Cómo realizar el manejo de los objetos (cargarlos/guardarlos)?

Unit Of WorkIdentity MapLazy Load

Patrones Estructurales Objeto-Relacional

¿Cómo mapear los conceptos de la OO a la base de datos relacional?

Identity FieldForeing Key MappingAssociation Table MappingDependent MappingEmbedded ValueSerialized LOBInheritance Patterns…Inheritance Mapper

Patrones de Mapeo de Metadatos Objeto-Relacional

¿Cómo definir declarativamente el mapeo objeto-relacional y encapsularlo, proponiendo una interfaz orientada a objetos?

Metadata MappingQuery ObjectRepository

Presentación

Dominio

Acceso a Datos


PATRONES ARQUITECTONICOS

Table Data Gateway


Un objeto que actúa como Gateway a una tabla de base de datos.

Una instancia maneja todas las filas en la tabla.

Presentación

Dominio

Acceso a Datos

23/05/2015

7


¿Cómo Trabaja?

Características: Su interfaz consiste de:

Métodos find para obtener información desde la BD

Métodos de actualización: insert, update, delete

Cada método ejecuta una sentencia SQL de acuerdo a sus parámetros.

Generalmente es stateless, ya que su rol es transferir datos entre el dominio y la BD.

En las consultas, siempre retorna un conjunto de datos: Map, RecordSet, DTOs

Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales Table Data Gateway

Presentación

Dominio

Acceso a Datos


¿Cuándo Utilizarlo?

Dado que su implementación es muy sencilla, sería apropiado para aplicaciones muy pequeñas que no cuentan con una lógica de acceso a datos compleja.

Si se ha decidido utilizar Table Modules para resolver la lógica de domino. Table Data Gateway es el mejor socio para estos casos, ya que produce los record sets que requiere un Table Module.

También es apropiado para Transaction Scripts, siempre y cuando el resultset sea conveniente para el Transaction Script.

La misma interfaz sirve para utilizar sentencias SQL directas o storedprocedures.

El resto de los casos.

Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales Table Data Gateway

Presentación

Dominio

Acceso a Datos


Row Data Gateway


Un objeto que actúa como Gateway a un único registro en una

tabla de base de datos. Hay una instancia por fila.

Presentación

Dominio

Acceso a Datos

Un Row Data Gateway permite obtener objetos que lucen como los registros de una tabla, pero pueden ser accedidos a través de las facilidades del lenguaje de programación utilizado. De esta manera, se encapsula toda la lógica específica (generalmente SQL) de acceso a datos dentro del gateway.


¿Cómo Trabaja?

Imita exactamente un registro de la base de datos, de manera tal que cada columna de la tabla es un campo del objeto.

Realiza todas las conversiones necesarias entre los tipos de datos de la base de datos y los tipos del lenguaje de programación.

Trabaja particularmente bien con Transaction Script.

Métodos de búsqueda:

Métodos estáticos.

Objetos de búsqueda (buscadores).

¿Cuál es diferencia entre Row Data Gateway y Active Record? La clave está en si existe lógica de dominio en estos objetos.

Row Data Gateway Sin lógica de dominio

Active Record Con lógica de dominio

Si bien es bastante tedioso de escribir, es muy utilizado por los generadores de código basados en Metadata Mapping.

Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales Row Data Gateway

Presentación

Dominio

Acceso a Datos



Funcionamiento del Row Data gateway



Principalmente, cuando se usa Transaction Script. Así, se factoriza el código de acceso a los datos y se lo reutiliza entre distintos scripts.

No sería conveniente utilizarlo en conjunto con Domain Model. Opciones:

• Si el mapeo es simple, usar Active Record.

• Si el mapeo es más complejo, usar Data Mapper.

• Si se utiliza para aislar a los objetos de domino de la estructura de base de datos, se tendrán 3 representaciones de los datos: una en los objetos de dominio, una en los Row Data Gateways y una en la base de datos.


Presentación

Dominio

Acceso a Datos

23/05/2015

8


Active Record


Un objeto que wrappea una fila de una tabla de la base de datos,

encapsula la lógica de acceso a datos y agrega lógica de dominio

sobre aquellos datos.

Presentación

Dominio

Acceso a Datos

Active Record utiliza la opción más obvia: pone la lógica de acceso a datos en el objeto de dominio. De esta manera, todos los objetos de dominio conocen como guardar y leer sus datos.


¿Cómo Trabaja?

La esencia de un Active Record es un Domain Model en el cual las clases se corresponden bastante con la estructura de tablas de la base de datos subyacente.

Cada Active Record es responsable tanto de guardarse y cargarse en/desde la base de datos, como de cualquier lógica de dominio que actúe sobre los datos.

Típicamente tiene métodos para:

Construir una instancia del Active Record a partir de una fila de un result set SQL.

Construir una nueva instancia que luego será insertada en la base de datos.

Métodos de búsqueda estáticos para factorizar queries SQL repetitivas y retornar instancias del Active Record.

Insertar y actualizar los datos del Active Record en la base de datos.

Obtener y asignar valores a los campos del Active Record.

Implementar algunas partes de la lógica de negocio.

Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales Active Record

Presentación

Dominio

Acceso a Datos


¿Cómo Trabaja? (Cont)

Los métodos get y set pueden realizar otras funciones como, por ejemplo, convertir tipos orientados a SQL a tipos propios del lenguaje de programación.

Se diferencia de Row Data Gateway en que Active Record contiene lógica de negocio.

Puede utilizar métodos de búsqueda estáticos o puede utilizar objetos de búsqueda (finders).


Presentación

Dominio

Acceso a Datos



Es una buena elección para la lógica de dominio que no sea demasidocompleja, tales como operaciones CRUD. Validaciones basadas en los datos de un único registro también funcionan bien.

Tiene la ventaja de la simplicidad comparado con Data Mapper.

Funcionan bien solamente si los objetos Active Record se corresponden directamente con las tablas de la base de datos.

Es un buen patrón a considerar si se está usando Transaction Script y se comienzan a sufrir sus desventajas (duplicación de código, mantenimiento, etc).

Si la lógica de dominio es más compleja, se querrán usar relaciones directas a objetos, colecciones, herencia, etc; cosas que no son fáciles de resolver con Active Record.

Acopla el diseño de objetos al diseño de base de datos.


Presentación

Dominio

Acceso a Datos


Data Mapper


Una capa de Mappers que mueven datos entre los objetos y la

base de datos manteniéndolos independientes unos de otros y del

mapper en sí mismo.

Presentación

Dominio

Acceso a Datos

Los Data Mappers separan los objetos en memoria de la base de datos. Son responsables de transferir los datos entre ambos y de mantenerlos aislados uno de otro.


¿Cómo Trabaja?

Hay muchas formas de construir una capa de Data Mappers. Sin embargo, veremos ejemplos sencillos para entender la idea.

Patrones de Diseño Empresariales Mapeando a Bases de Datos Relacionales Data Mapper

Presentación

Dominio

Acceso a Datos

Recuperar datos de una base de datos.

23/05/2015

9


Cantidad de Mappers

Hardcoded: Uno por cada clase de dominio o raíz de un agregado.

Metadata Mapping: Unico mapper para todas las clases. Finders agrupados por clase de dominio.


Presentación

Dominio

Acceso a Datos

Actualizando datos


Identidad de los objetos

Es necesario que exista en todo momento una única representación en memoria de un objeto de domino, identificada por su identidad.

Hay dos opciones:

Registry de Identity Maps

Cada clase finder mantenga su propio Identity Map, asegurando que habrá solamente una clase finder por cada entidad de negocio.

Manejo de Finders

Varias veces una clase de dominio necesita acceder a un finder de otra clase de dominio

Nunca agregar una dependencia desde un objeto de dominio al Data Mapper.

Utilizar Separated Interface, creando una interfaz con todos los métodos findersrequeridos por la clase de domino y ubicándola en el paquete de dominio.


Presentación

Dominio

Acceso a Datos


Mapeos Basados en Metadatos

Código explícito

Implica tener un mapper por cada objeto de negocio.

El mapeo se realiza a través de asignaciones y sentencias SQL que mantiene internamente

Metadata Mapping

Mantiene la metadata de mapeo como datos, ya sea en la misma clase de dominio o en una clase separada.

Existen distintas variantes para metadatas: XML, atributos/anotaciones, fluentinterfaces, modelos graficos.

Ejemplos

Java: JPA, Hibernate, EJB, MyBatis, TopLink

.Net: Entity Framework, Nhibernate, Linq to SQL

PHP: CakePHP, Propel, Doctrine

Android: OrmLite, SugarORM


Presentación

Dominio

Acceso a Datos



Cuando queremos que el esquema de base de datos y el modelo de dominio evolucionen independientemente

Cuando utilizamos Domain Model. Si bien se podría utilizar Active Record, cuando las cosas se ponen más complejas, Data Mapper toma ventaja.

Si se tiene un modelo de negocio simple.

Si no se quiere pagar el costo de una capa extra.

Si hay que construirlo desde cero.


Presentación

Dominio

Acceso a Datos

Un data mapper es un monstruo complicado de construir.

Hay productos que ya resuelven la problemática, están

testeados e implementan muchos de los patrones vistos.


¿Cómo trabaja? Cuando se comienza a trabajar con la BD, se crea un UoW

UoW mantiene registro de todos los objetos creados / modificados / eliminados durante la transacción de negocio.

Al finalizar la transacción de negocio, el UoW decide qué hacer:

Abrir una transacción de BD

Realizar chequeos de concurrencia (optimista)

Escribir cambios a la BD en el orden apropiado

Cerrar la transacción de BD

Patrones de Diseño Empresariales Mapeando a BD Relacionales Patrones de Comport. Objeto-Relacional

PATRONES DE COMPORTAMIENTO OBJETO-RELACIONAL

Unit Of Work

Presentación

Dominio

Acceso a Datos

Mantiene una lista de objetos afectados por una transacción de

negocio y coordina la escritura de los cambios y la resolución de

problemas de concurrencia.


¿Cómo utilizarlo? Ya viene implementado en muchos ORMs:

Hibernate Session

Entity Framework Context

etc.

Construirlo desde cero es factible, aunque requeriría bastante esfuerzo.

Muchas veces se encapsula (wrappea) el UoW provisto por el ORM

Para evitar tener referencias al ORM en la capa de negocios/aplicación

Para extenderlo con el fin de agregarle features

Manejo de transacciones distribuidas (múltiples BDs)

Logging

Realizar acciones luego del cierre de la transacción de BD.


Presentación

Dominio

Acceso a Datos

23/05/2015

10


¿Cómo trabaja? Mantiene registro de todos los objetos que han sido leídos desde la BD en

una única transacción de negocio.

Cuando se quiere obtener un objeto, primero se busca en el map por si ya está. Si no está, se busca en la BD y se lo incorpora al map.

Si se utiliza el concepto de Unit Of Work, entonces el UoW es el mejor lugar para el Identity Map.

También sirve como caché de los objetos obtenidos en una transacción de negocio.


Identity Map Presentación

Dominio

Acceso a Datos

Asegura que cada objeto sea cargado solamente una vez,

manteniendo cada objeto cargado en un map. Busca objetos a

través del map cuando se los referencia.


¿Cómo trabaja? Lazy Load interrumpe el proceso de carga de objetos relacionados al objeto

que se quiere recuperar, dejando una marca en la estructura de objetos tal que si el dato es necesario, pueda ser cargado solamente cuando sea usado.

Alternativas de implementación: Lazy initialization, Virtual proxy, Valueholder, Ghost

¿Cuándo utilizarlo? Actualmente lo proveen por defecto muchos ORMs.

Balancear la información que se recupera en un acceso versus la cantidad de accesos que se requerirán para recuperar la información necesaria.

Principalmente se utiliza para colecciones de objetos relacionados.

Cuidado con el problema del N+1 !


Lazy Load Presentación

Dominio

Acceso a Datos

Un objeto que no contiene todos los datos que necesitas, pero

sabe cómo obtenerlos.


¿Cómo trabaja? Elegir la clave

Claves con o sin sentido

Meaningful key: Por ejemplo, el número de documento de una persona

Meaningless key: Número aleatorio que no sería utilizado por humanos.

Claves simples o compuestas

Clave simple: Solamente usa un campo de la base de datos.

Clave compuesta: Usa más de un campo de la base de datos.

Alcance de unicidad de las claves

Únicas por tabla

Únicas por base de datos

Patrones de Diseño Empresariales Mapeando a BD Relacionales Patrones Estructurales Objeto-Relacional

PATRONES ESTRUCTURALES OBJETO-RELACIONAL

Identity Field

Presentación

Dominio

Acceso a Datos

Guarda el campo ID de la base de datos en el objeto para

mantener la identidad entre un objeto en memoria y la fila de la

base de datos


¿Cómo trabaja? Elegir la clave (cont.)

Tipo y tamaño

Las operaciones más frecuentes son: igualdad y siguiente clave

Pueden tener efecto en la performance e índices de las BDs.

Generalmente se utilizan: long, GUID e int.

Representar el Identity Field en un objeto

La forma más simple de Identity Field es un campo que concuerde con el tipo de la clave en la BD

Para las claves compuestas, generalmente se utiliza una clase que las representa.

Muchas veces se factoriza la definición de la clave (junto con la operación de igualdad) en una clase de entidad base y ese comportamiento es heredado por todas las entidades del sistema.

Obtener una nueva clave

Delegar en la BD y que la auto-genere

Usar un GUID

Generar propias (max function, tabla de claves separada)


Presentación

Dominio

Acceso a Datos


¿Cómo trabaja?


Foreign Key Mapping Presentación

Dominio

Acceso a Datos

Mapea una asociación entre objetos a una foreing key entre tablas

Mapeando una referencia Mapeando una colección


¿Cómo trabaja?


Association Table Mapping Presentación

Dominio

Acceso a Datos

Guarda una asociación con una tabla con foreign keys a las tablas

que están linkedas por la asociación.

23/05/2015

11


¿Cómo trabaja? El objeto dependiente:

Sólo tiene un owner

No puede haber referencias a él desde otro objeto que no sea su owner

No tiene un Identity Field

No es almacedo en el IdentityMap

No puede ser buscado directamente.

Sólo es accedido desde su owner

Generalmente es un Value Object


Dependent Mapping Presentación

Dominio

Acceso a Datos

Una clase tiene que realizar el mapeo de BD para una clase hija


¿Cómo trabaja?


Embedded Value Presentación

Dominio

Acceso a Datos

Mapea un objeto en varios campos de la tabla de otro objeto


¿Cómo trabaja? Tipos de serialización:

BLOB: Binary LOB

CLOB: Textual characters LOB

Se diferencia con EmbeddedValue en que está orientado estructuras de objetos más complejas.


Serialized LOB Presentación

Dominio

Acceso a Datos

Guarda un grafo de objetos serializándolos en un único objeto

grande (LOB), el cual se almacena en un campo de la BD.


Single Table Inheritance


Representa una jerarquía de herencia de clases como una única

tabla que tiene columnas para todos los campos de las clases de la

jerarquía

Presentación

Dominio

Acceso a Datos


¿Cómo Trabaja?

Existe una tabla que contiene todos los datos para todas las clases de la jerarquía.

Cuando se carga un objeto a memoria, se necesita conocer qué clase instanciar:

Se necesita un campo extra en la tabla que indique qué clase debiera utilizarse para esa fila.

Nombre de la clase

Código discriminador


Presentación

Dominio

Acceso a Datos


Fortalezas y Debilidades Habrá una única tabla por la que preocuparse

No se realizan joins para recuperar información

Cualquier refactoring que eleve/baje campos de la jerarquía no requiere que se cambie la BD.

Los nombres de columnas a veces son relevantes y a veces no, lo cual puede confundir a personas que accedan directamente a la BD.

Las columnas que sólo son utilizadas por algunas subclases conducen a desperdiciar espacio.

La tabla podría terminar siendo muy grande, con muchos índices y frecuentes bloqueos, lo cual afectaría la performance.

Sólo se tiene un único namespace para los nombres de los campos, con lo cual se debe asegurar que no existan dos campos en el jerarquía con el mismo nombre… o definir una política que resuelva estas cuestiones.


Presentación

Dominio

Acceso a Datos

23/05/2015

12


Class Table Inheritance


Representa una jerarquía de herencia de clases con una tabla para

cada clase

Presentación

Dominio

Acceso a Datos


¿Cómo Trabaja?

Existe una tabla por clase en la jerarquía de herencia.

Los campos en la clase de domino se mapean directamente a los campos de la tabla correspondiente.

¿Cómo enlazar las filas en distintas tablas que representan a un objeto concreto de la jerarquía?

Usar un valor de clave primaria común a la jerarquía

En la superclase se asegura la unicidad de las claves

Cada tabla tiene sus propias claves primarias. Entonces, usar foreign keys en la tabla de la superclase para apuntar al resto de las filas.

El problema más desafiante es cómo recuperar los datos desde múltiples tablas de manera eficiente

Queries separadas, joins… tienen un costo alto de performance en muchos casos.


Presentación

Dominio

Acceso a Datos


Fortalezas y Debilidades Todas las columnas son relevantes para cada fila. Por lo tanto las tablas son

fáciles de entender y no desperdician espacio.

La relación entre el modelo de dominio y la base de datos es directa.

Se necesita acceder a múltiples tablas para cargar un objeto (un join o múltiples queries, más el armado en memoria)

Cualquier refactoring que eleve/baje campos de la jerarquía causa cambios en la BD

Las tablas de los supertipos podría convertirse en un cuello de botella ya que sería accedidas con mucha más frecuencia que las tablas de las hojas de la jerarquía

La alta normalización puede hacer que sea difícil entender las queries


Presentación

Dominio

Acceso a Datos


Concrete Table Inheritance


Representa una jerarquía de herencia de clases con una tabla por

clase concreta de la jerarquía

Presentación

Dominio

Acceso a Datos


¿Cómo Trabaja?

Existe una tabla para cada clase concreta de la jerarquía de herencia.

Cada tabla contiene las columnas para los campos propios de la clase concreta y para los campos de todos sus ancestros. Por lo tanto, los campos de las superclases son duplicados en las tablas de sus subclases concretas.

Se necesitan claves que sean únicas para toda la jerarquía.

Existe un problema con la integridad referencial, ya que no existe la posibilidad que los clientes de la jerarquía fuercen una referencia a clases no-concretas.

Ignorar integridad referencial.

Utilizar múltiples tablas de enlace, una para cada tabla real en la BD.


Presentación

Dominio

Acceso a Datos


Fortalezas y Debilidades Cada tabla es auto-contenida y no tiene campos no relevantes. Esto es

favorable cuando las tablas serán utilizadas también por otros sistemas que no estén usando objetos.

No se necesitan joins para leer datos.

Cada tabla es accedida solamente cuando la clase correspondiente es accedida.

Las claves primarias pueden ser difíciles de manejar.

No se pueden forzar relaciones de base de datos a clases abstractas.

Cualquier refactoring que eleve/baje campos de la jerarquía causa cambios en la BD, aunque no tantos como en Class Table Inheritance.

Si cambia un campo de una superclase, se deben modificar todas tablas que contengan dicho campo.

Una búsqueda sobre la superclase fuerza a chequear todas las tablas.


Presentación

Dominio

Acceso a Datos

23/05/2015

13


Patrones de Diseño Empresariales Mapeando a BD Relacionales Patrones de Metadatos Objeto-Relacional

PATRONES DE MAPEO DE METADATOSOBJETO-RELACIONAL

Repository

Presentación

Dominio

Acceso a Datos

Sirve de intermediario entre la capa de dominio y la de mapeo de

base de datos, usando una interfaz símil colección para acceder a

los objetos de dominio.

Repositories

Data Mapper

Data Access Layer Un Repository media entre las capas de

dominio y de mapeo de datos, actuando como una colección de objetos de dominio en memoria.

Encapsula un conjunto de objetos homogéneos persistidos en un almacenamiento de datos, junto con las operaciones realizadas sobre ellos.


¿Cómo Trabaja?

Para el código que usa al Repository, parece una simple colección en memoria de objetos de dominio.

Remplaza los métodos finder de las clases Data Mapper por una aproximación basada en especificaciones para seleccionar objetos.

No hay noción de ejecución de una query, sino más bien de satisfacción de una criterio de selección.

El destino de un Repository podría no ser una base de datos relacional. Esto permite reemplazarlos por implementaciones alternativas que, por ejemplo, faciliten la definición de tests unitarios y agilicen su ejecución.

Son un buen mecanismo para mejorar la legibilidad del código que usa extensivamente consultas.


Presentación

Dominio

Acceso a Datos


¿Cuándo se usa? Reduce la cantidad de código necesario para tratar con la interacción con la

base de datos.

Promueve el patrón Specification (por ej., en forma de objetos de criterio) que encapsula la query a realizarse de una manera orientada a objetos.

Los clientes nunca tienen que pensar en términos de SQL, sino mas bien en términos de objetos.

Permite tener distintas alternativas de implementación a muy bajo costo (unit tests).

En sistemas muy simples que no requieran de mucha complejidad.


Presentación

Dominio

Acceso a Datos


Web Presentation


Presentación

Dominio

Acceso a Datos

Input Controller Patterns Model View Controller

Page Controller

Front Controller

View Patterns Transform View

Template View

Two Steps View


Model View Controller

Patrones de Diseño Empresariales Web Presentation

Separa la interacción de la interfaz de usuario en tres roles

distintos

Presentación

Dominio

Acceso a Datos

Es uno de los patrones de diseño más conocidos , teniendo influencia desde sucración (1970) en muchos UI frameworks y en la forma de pensar sobre el diseño de interfaces de usuario.

View Controller

Model


¿Cómo Trabaja?

Roles Model

Es un objeto que representa al dominio, contiene datos y comportamientodistinto a los de la UI

En su forma más OO pura, sería un objeto del Domain Model

También podría ser un Transaction Script del Dominio

View

Representa la visualización del modelo en la interfaz de usuario

Sólo conoce como mostrar la información

Controller

Toma información del request, invoca al objeto del modelo correspondiente y, en base a los resultados obtenidos, determina qué vista es la apropieda paramostrar. Luego le pasa el control a la vista, junto con los datos de respuesta.

Toma la entrada del usuario, manipula el modelo y refresca la vista apropiadamente.

Patrones de Diseño Empresariales Web Presentation Model View Controller

Presentación

Dominio

Acceso a Datos

23/05/2015

14


Interacción entre el modelo, la vista y el controlador.


Presentación

Dominio

Acceso a Datos


Principales Separaciones Presentación del modelo

Es uno de los más importantes principios de diseño.

Generalmente tienen intereses distintos

Al desarrollar una vista, nos preocupamos por mecanismos de UI y por cómo diseñaruna buena UI.

Al trabajar con el modelo, se piensa en términos de reglas de negocio y, quizás, de interacciones con la base de datos.

Se podría querer ver la misma información del modelo de distintas formas.

Objetos no visuales son más fáciles de testear que objetos visuales.

La presentación depende del modelo pero el modelo no depende la presentación.

Controlador de la vista

No es tan importante, pero igualmente brinda beneficios. Permitiría tener másde un controlador por vista, o distintas vistas usar el mismo controlador.

Ejemplo: Soportar comportamiento de edición y visualización con una vista.

Podríamos tener 2 controladores, uno para cada caso, donde los controladores son Strategies (GoF) de la vista.


Presentación

Dominio

Acceso a Datos



Cuando las separaciones indicadas anteriormente (especialmente la separación de la presentación y el modelo) son útiles.

Si se tiene una aplicación muy simple donde el modelo no tiene comportamiento.

Si las tecnologías a utilizar no brindan la infraestructura necesaria.

Ejemplos Java

Spring MVC, Struts, JSF, Seam, Tapestry, etc.

.Net

ASP.NET MVC

PHP

CakePHP, Lamplighter (ex-Fuse), Symfony

Javascript

Backbone.js, Knockout.js, JavascriptMVC, Angular.js, etc.


Presentación

Dominio

Acceso a Datos


Page Controller


Un objeto que maneja un request para una página o acción

de una aplicación web.

Presentación

Dominio

Acceso a Datos

Page Controller tiene un controlador para cada página lógica de la aplicación web. El controlador puede ser la página en sí misma (frecuente en ambiente server pages), o puede se un objeto separado que se corresponda con aquella página. Sin embargo, este patrón de diseño apunta a una alternativa de un path que conduce a un archivoque maneja un requerimiento.


¿Cómo Trabaja?

Idea básica Un módulo (clase o lo que fuera) actúa como controlador para cada página de la

aplicación web.

En la realidad, existirá un controlador por cada acción (incluidas los eventos)

Responsabilidades Decodificar la URL y extraer cualquier dato del request que sea necesario

para realizar la acción requerida.

Crear e invocar objetos del modelo para procesar los datos de entrada. Los objetos del modelo no necesitan conocer al request.

Determinar qué vista se debe mostrar y enviarle el modelo quecorresponda.

Patrones de Diseño Empresariales Web Presentation Page Controller

Presentación

Dominio

Acceso a Datos


Formas de Implementación Script

CGI script, Servlet, etc.

Script que actúa como handler y controlador

El web server le pasa el control al script, el script lleva a cabo las responsabilidades de un controlador y finalmente transfiere el control a la vista que corresponda.

Server Page

ASP, ASP.NET, PHP, JSP, etc

Generalmente combina los patrones Page Controller y Template View en un mismo archivo. Esto favorece al Template View en detrimento del Page Controller.

Para evitar scriptlets

Utilizar helpers: La server page llama, en primer lugar, al helper para que maneje la lógica. Luego el helper le retorna el control a la página o se lo transfiere a otra.

Recomendaciones

No necesita ser una única clase

Se podrían tener ambas alternativas en una misma aplicación.


Presentación

Dominio

Acceso a Datos

23/05/2015

15


Ejemplos Página de visualización simple con un servlet Page Controller y una vista JSP


Presentación

Dominio

Acceso a Datos


Ejemplos Usando un página JSP como un handler


Presentación

Dominio

Acceso a Datos



Cuando mucha de la lógica del controlador es muy simple, ya que no agrega demasiado overhead.

Cuando hay mucha complejidad navegacional, sería preferible para el costo de un Front Controller.


Presentación

Dominio

Acceso a Datos


Front Controller


Un controller que maneja todos los request para una

aplicación web.

Presentación

Dominio

Acceso a Datos

Front Controller consolida el manejo de requests, canalizándolos a través de un único objeto handler. Este objeto lleva adelante comportamiento común (seguridad, i18n, logging, etc.) y luego despacha el request a un command para realizar el comportamiento específico.


¿Cómo Trabaja?

Idea básica Un Front Controller maneja todas las llamadas a una aplicación web

Está estructurado en 2 partes: un web handler y una jerarquía de comandos.

Web Handler

Es el objeto que realmente recibe POSTs y GETs del web server

Obtiene información de la URL y del request para decidir qué tipo de acción iniciar

Delega al command correspondiente la atención del requerimiento.

Generalmente es implementado como una clase y no con una server page. No produce ninguna respuesta por sí mismo.

Comandos

Son clases y no server pages

Generalmente no necesitan conocimiento del ambiente web, aunque muchas veces se les pasa el request HTTP.

Patrones de Diseño Empresariales Web Presentation Front Controller

Presentación

Dominio

Acceso a Datos


Selección del comando Estática

Parsea la URL y utiliza lógica condicional

Tiene las ventajas de la lógica explícita:

Chequeos en compilación

Flexibilidad en el formato de la URL

Dinámica

Utiliza un patrón de URL y utiliza instanciación dinámica para crear comandos.

Permite agergar nuevos comandos sin cambiar el web handler.

Implementación

Poner el nombre de la clase comando en la URL

Usar properties files / XMLs para mapear las URLs con los comandos.

Uso con Intercepting Filter Es un decorador que wrappea al web handler de un Front Controller

permitiendo construir un pipe & filter

Permite manejar autenticación, logging, i18n, etc.


Presentación

Dominio

Acceso a Datos

23/05/2015

16


Ejemplos


Presentación

Dominio

Acceso a Datos



Si las ventajas pagan el esfuerzo:

Sólo un Front Controller tiene que ser configurado en el web server.

Con comandos dinámicos, se podrían agregar comandos sin ningún cambio más que en la configuración.

No es necesario que los comandos sean thread-safe, ya que son creados por cada request

Permite factorizar código que, de otra forma, estaría duplicándose en las Page Controller.

Se puede mejorar el comportamiento del Front Controller, a través de decoradores para autenticación, codificación de caracteres, i18n, etc, y agergarlos a través de un archivo de configuración.

Es más complejo que un Page Controller.


Presentación

Dominio

Acceso a Datos


Template View


Renderiza información en HTML embebiendo markers en

una página HTML.

Presentación

Dominio

Acceso a Datos

HTML Estático + Markers Especiales = Página Web Dinámica


¿Cómo Trabaja?

Idea básica Embeber markers en una página HTML cuando ésta es escrita.

La página puede ser diseñada de la manera usual, con editores WYSIWYG.

Embebiendo los markers Tags del estilo HTML

Trabajan bien con editores WYSIWYG

Con tags XML bien formados, se pueden usar herramientas de manejo de XML para editar las páginas, permitiendo que la página sea diseñada como HTML

Además de proveer un conjunto estándar de tags, muchos ambientes permitedefinir tags propios que satisfagan las necesides.

Text markers

Los editores WYSIWYG los ignoran, aunque a veces pueden meter ruido (spell checking)

La sintáxis puede ser más simple que los toscos XML / HTML

Patrones de Diseño Empresariales Web Presentation Template View

Presentación

Dominio

Acceso a Datos


Scriptlets o no scriptlets Definición

Server pages (ASP, JSP, PHP) generlamente permiten embeber lógica de programación arbitraria en las páginas, llamada scriptlets.

Si bien pueden ser pragmáticos en algun sentido, conviene mantenerlos a raya, limitándonos al comportamiento estándar de un Template View.

Desventajas

Elimina la posibilidad de que los diseñadores gráficos diseñen las páginas.

La página pierde su estructura y, con ello, su capacidad de componentización (o modularización).

Podrían llegar a confundir las diferentes capas de una aplicación empresarial.

Helper objects Tienen toda la lógica de programación real.

Una página solamente lo invoca, lo cual simplifica a la página y la hace másTempalte View pura.

Es la manera de minimizar el uso de scriptlets

Permite que los diseñadores gráficos diseñen la página, mientras que los programadores se concentran en los helpers


Presentación

Dominio

Acceso a Datos


Comportamiento condicional en la página Definición

Caso simple: algo debe mostrarse si se cumple una condición <IF condition=“precio > 10”> hacer algo </IF>

Desventajas

El sobreuso lleva a convertir el template en un lenguaje de programación

Esto conduce a los mismos problemas que los scriptlets.

Soluciones

Si se necesita mostrar un texto de manera condicional, mover la condición a un helper.

Si se quiere resaltar un item de una lista

Hacer que el helper genere el código markup.

Generar un tag preciso para resolver la problemática.


Presentación

Dominio

Acceso a Datos

<IF expression = "isHighSelling()"><B></IF>

<property name = "price"/>

<IF expression = "isHighSelling()"></B></IF>

<highlight condition = "isHighSelling" style = "bold">

<property name = "price"/>

</highlight>

23/05/2015

17


Iteración La iteración sobre una colección presenta los mismos problemas

que el comportamiento condicional.

No se puede escapar al tag de iteración, generalmente provisto por la plataforma.

Rol del Template View Template View tiende a ser la vista en un MVC.

En muchos sistemas, sólo jugará ese rol.

En otros, generalmente más simples, podrá jugar el rol del controller y, posiblemente, el del modelo (aunque esto último es importante que se evite)

Es importante asegurar que estas responsabilidades sean manejadas por el helper, y no por la página, ya que involucran logica de programación.

Cuándo procesar Compilando la página luego que es creada

Compilando la página en su primer request

Interpretando la página en cada request.


Presentación

Dominio

Acceso a Datos


Manejo de Excepciones Los errores durante la compilación/interpretación de un

Template View, generalmente no tienen red de contención.

Asegurar que la aplicación maneje estos errores.


Presentación

Dominio

Acceso a Datos


Ejemplo Usando un página JSP como una Vista con un Controller Separado

Controller

Definición del helper en la vista

Helper (parcial)


Presentación

Dominio

Acceso a Datos


Ejemplo (cont.) Definición de propiedad en el helper

Uso de la propiedad

Iterador


Presentación

Dominio

Acceso a Datos

Scriptlet

OK !



Permite comprender el contenido de la página mirando la estructura de la página.

Esto permite que diseñadores gráficos puedan trabajar con las páginas, enfocando a los programadores a la resolución de los helpers.

La implementación más común hace muy fácil poner lógica complicada en la página, comprometiendo su mantenibilidad.

Es más difícil de testear que Transform View


Presentación

Dominio

Acceso a Datos


Transform View


Una vista que procesa datos del modelo elemento por

elemento y los transforma en HTML

Presentación

Dominio

Acceso a Datos

Usar Transform View para resolver la vista en MVC significa pensarlo como una transformación donde los datos del modelo conforman la entrada de dicha transformación y el HTML la salida.

23/05/2015

18


¿Cómo Trabaja?

Idea básica Escribir un programa que recorra los datos devueltos por el dominio y los

convierta a HTML:

Atraviesa la estructura de datos del dominio

Reconoce a cada dato

Escribe la sección de HTML particular para el dato.

Diferencias con Template View La forma en la cual la vista está organizada

Template View: Orientada a la salida

Transform View: Orientada a la entrada

Patrones de Diseño Empresariales Web Presentation Transform View

Presentación

Dominio

Acceso a Datos


Implementación XSLT es la más frecuente

Es un lenguaje de programación funcional

Tiene un tipo diferente de estructura: más bien que explícitamente llamar a procedimientos, XSLT reconoce elementos en los datos del modelo e invoca lastransformaciones apropiadas.

Requiere que la entrada sea un XML

Si el tipo de retorno natural de la lógica de dominio es XML o algo automáticamentetransformable a XML (por ej, objetos .NET)

Poblando un Data Transfer Object que sepa serializarse a XML.


Presentación

Dominio

Acceso a Datos

XSL EngineXMLModel

XSLTView

HTML


Ejemplo Objeto command (GoF) que oficia de controller:

Documento XML


Presentación

Dominio

Acceso a Datos


Ejemplo (cont.) View


Presentación

Dominio

Acceso a Datos



XSLT es portable a casi todas las plataformas web.

Es más simple de usar si los datos vienen como XML

Evita dos grandes problemas de Template View:

Es más fácil enfocarse solamente en la renderización de HTML, evitando meter lógica en la vista

Es más fácil ejecutar la Transform View y obtener la salida para testearla.

Si bien hay herramientas para trabajar con XSLT, no son tan sofisticadas como las existentes para Template Views.

XSLT puede ser un lenguaje difícil de aprender por su naturaleza funcional.


Presentación

Dominio

Acceso a Datos


Two Step View


Transforma datos del dominio en HTML en dos pasos:

primero construyendo algún tipo de página lógica, y luego

renderizando la página lógica a HTML

Presentación

Dominio

Acceso a Datos

Muchas veces se quiere realizar un cambio en el look & feel de la aplicación. Two Steps View ataca este problema, separando la transformación en dos etapas: 1. Transforma los datos del modelo en

una presentación lógica sin ningún formateo específico.

2. Convierte la representación lógica con el formateo apropiado.

23/05/2015

19


¿Cómo Trabaja?

Idea básica Hacer la transformación en un proceso de 2 etapas

Ensamblar la información en una estructura de pantalla lógica que sea descriptiva de los elementos de pantalla sin usar HTML

Su responsabilidad es acceder al modelo orientado al dominio (una base de datos, un modelo de dominio real o un DTO), extraer la información relevante para la pantalla, y poner dicha información en una estructura orientada a la presentación.

Dicha estructura podría incluir campos, encabezados, pie de página, tablas, selectores, etc.

Tomar la estructura orientada a la presentación y renderizarla en HTML

Conoce cada elemento de la estructura orientada a la presentación y genera el HTML correspondiente.

Patrones de Diseño Empresariales Web Presentation Two Steps View

Presentación

Dominio

Acceso a Datos


¿Cómo Trabaja?

Implementaciones Two-Steps XSLT

Hay 2 XSLT style-sheets

Transforma el XML orientado al dominio en un XML orientado a la presentación

Transforma el XML orientado a la presentación a HTML

Clases

Se define la estructura orientada a la presentación como un conjunto de clases: una clase tabla, una clase fila, etc.

Etapa 1: Toma la información del dominio e instancia estas clases en una estructuraque modele una pantalla lógica.

Etapa 2: Renderiza las objeto a HTML, haciendo que cada objeto genere su HTML o teniendo un generador separado.


Presentación

Dominio

Acceso a Datos



Permite realizar cambios globales con mayor facilidad.

Resuelve dos situaciones particulares:

Aplicaciones web multi-apariencia: Se necesita que cada cliente pueda determinar su look & feel.

Aplicaciones web mono-apariencia: Se necesita una look & feel consistente durante toda una aplicación.

Para variaciones de multi-apariencia, donde se pueden generar dos tipos distintos de HTML: para browser y para mobile.

Si tenemos una aplicación intensiva en diseño, donde cada página se ve distinto.

Hay muy pocas herramientas para trabajar con esta alternativa.


Presentación

Dominio

Acceso a Datos


Application Controller


Un punto centralizado para manejar navegación entre

pantallas y el flujo de una aplicación.

Presentación

Dominio

Acceso a Datos

Algunas aplicaciones tienen una significativa cantidad de lógica para determinar qué pantalla debe mostrarse en cada momento (como los wizards). Application Controllerataca este problema, haciéndose cargo de este tipo de lógica de flujo de pantallas.


¿Cómo Trabaja?

Responsabilidades Decidir qué lógica de dominio ejecutar

Decidir la vista con la que se debe mostrar la respuesta

¿Cómo lo separo del resto de la aplicación? El Application Controller tiene dependencias con el UI engine

Accede a los datos de la sesión HTTP

Realiza un forward a una server page

Invoca métodos de una clase rich-client

El Application Controller NO tiene dependencias con el UI engine

Favorece el testeo unitario de los Application Controllers, independientementede la UI.

Se puede usar el mismo Application Controller para múltiplespresentaciones/vistas.

Patrones de Diseño Empresariales Web Presentation Application Controller

Presentación

Dominio

Acceso a Datos


¿Cómo se implementa? Tanto para la funcionalidad del domino como para la vista , el Application

Controller necesita una manera de almacenar algo que pueda invocar.

El patrón Command [GoF] sería una buena elección, ya que permite mantener y ejecutar fácilmente un bloque de código.

2 colecciones

Los objetos de dominio pueden ser:

Comandos que forman parte de la capa de Application Controllers

Referencias a Transaction Scripts

Las vistas son, generalmente, server pages. Si se usan clases, un comando o un string para hacer llamadas por reflection es de gran utilidad.


Presentación

Dominio

Acceso a Datos

23/05/2015

20


Metadatos Una manera común de pensar en la UI de una aplicación es a

través de una máquina de estados

Ciertos eventos lanzan diferentes respuestas dependiendo del estado de ciertosotros objetos clave del negocio.

Esto favorece el uso de metadatos para representar el flujo de control de máquina de estados.


Presentación

Dominio

Acceso a Datos


Ejemplo Spring Web Flow


Presentación

Dominio

Acceso a Datos


Ejemplo (cont) Spring Web Flow


Presentación

Dominio

Acceso a Datos



Si tenemos un conjunto de reglas que determinan el orden en el cual las páginas serían accedidas, y diferentes vistas dependen del estado de los objetos.

Si en algún momento nos encontramos teniendo que realizar cambios similares en gran cantidad de lugares cuando el flujo de aplicación cambia.

Si la aplicación es lo suficientemente simple tal que cualquiera puede visitar cualquier pantalla sin un orden establecido.


Presentación

Dominio

Acceso a Datos

patrones de diseño empresariales - principalcs.uns.edu.ar/~atrellini/ayds/downloads/clases/14. ayds...

Documents