Arquitectura de Aplicaciones .NET

Diseño de aplicaciones y servicios

Carlos Walzer

carlos@walzer.com.ar

msmvps.com/blogs/cwalzer

Objetivo

• Diseñar arquitectura para aplicaciones y servicios

• Recomendar tecnologías apropiadas

• Cumplir requisitos funcionales y no funcionales

• Elegir los mecanismos de comunicación adecuados

Agenda

• Aplicaciones Distribuídas

• Diseño de los componentes de una aplicación o Servicio

• Aplicación ejemplo

Aplicaciones Distribuídas

Aplicaciones distribuídas

• Para que distribuir?

• Cumplir requerimientos funcionales– Conocimiento de los procesos empresariales

• Cumplir requerimientos no funcionales– Escalabilidad

– Disponibilidad

– Rendimiento

– Seguridad

– Mantenimiento

Servicios

• Que son?– Similiares a los componentes tradicionales

– Encapsulan funcionalidad y datos

– No forman parte de la App, son usados

– Plataformas heterogéneas

– Comunicación = Mensajes• Implícita

• Explícita

– Interfaz de Servicios = Contrato

Proceso basado en Servicios

Solución basada en Servicios

• Acoplamiento mínimo

• Aplicación tradicional de 3 niveles

• Sin UI asociada

• Transacciones atómicas

Componentes en Capas

Componentes y Servicios Relacionados

Diseño de los componentes de una aplicación o servicio

Tipos de Componentes

Al diseñar Aplicaciones o Servicios

• Identifique los componentes necesarios

• Diseño coherente de componentes de un tipo

• Formato de intercambio de datos homogeneo

• Abstraer código que aplica políticas de la funcionalidad

• Tipo de comunicación entre capas.

Capa de Interfaz de Usuario

Componentes de UI

• Distintas tecnologías disponibles

• Una página o formulario, controles, aceptan entrada de datos.

• Patrón View-Controler

Funcionalidades de los Componentes de UI

• No inicializan, participan ni votan en Tx.

• Referencian a un componente de Proceso en nombre del usuario corriente.

• Encapsulan funcionalidad de visualización.

Al aceptar la entrada del usuario

• Toman los datos del usuario

• Capturan los eventos del usuario y llaman a funciones de control

• Restringen los tipos de entrada del usuario

• Validan la entrada de datos

• Interpretan acciones de usuarios

Al procesar datos

• Adquieren los datos de utilizados por los componentes

• Formatean valores (fechas)

• Localización de los datos

• Funcionalidad de deshacer y copy & paste

Aspectos a tener en cuenta en UI

• Usar Data Binding

• Evitar que las excepciones lleguen al usuario

• No implemente funcionalidad en manejadores de eventos

private void addItem_Click(object sender, System.EventArgs e)

{

AddItemToBasket(selectedProduct, selectedQuantity)

}

public void AddItemToBasket(int ProductID, int Quantity)

{

// código para agregar el artículo a la cesta

}

Componentes de Proceso de Usuario

• Clases .NET con métodos llamados por Comp de UI

• Coordinan el proceso de usuario y mantienenel estado entre páginas o ventanas

• Coordinan visualización de la interfaz

• Se abstraen de la funcionalidad de procesamiento y adquisición de datos

• Ejemplo…

Ventajas

• Ejecución larga (carrito de compras)

• Varias UI pueden usar el mismo proceso– Nuevo dispositivo -> pueden requerir

recodificación

• Control de actividades concurrentes

• Sincronización de ventanas

• Estado de ejecución larga (guardar y continuar)

• Aplicaciones desconectada.

Interfaces de Componentes de procesos de UI

• 1 – Acciones de procesos de usuarios

• 2 – Métodos de acceso a Datos

• 3 – Eventos de cambios de estado

• 4 – Control de pausa, reiniciar y cancelar.

Capa de Reglas de Negocio Empresariales

Componentes de Reglas de Negocio o Empresariales

• Funcionalidad de proceso empresarial o Lógica de dominio

• Una o varias tareas

• Generalmente una tarea encapsulada en un Método (acción: Facturar, DescontarStock)

Componentes y flujos de trabajo empresariales

• Organizan componentes empresariales

• Usar flujos de trabajo cuando:

– Proceso de varios pasos y Tx de ejecución larga

– Orquestar procesos

– Participar con otros servicios

Componentes empresariales

• Raiz de una Tx atómica

• Implementan reglas de negocio

• Aceptan y devuelven estructuras de datos

• Independientes del almacenamiento

Implementación de Componentes Empresariales

• Invocados por la capa de usuario o interfaces de servicios

• Son la raíz de Tx, deben votar en Tx.

• Validan entrada y salida

• Operaciones de compensación

• Recuperan y actualizan datos llamando a componentes logicos de acceso a datos

• Pueden llamar a otros componentes empresariales o flujos

• Envían Excepciones

Llamados por

• Interfaces de servicios

• Componentes de procesos de usuario

• Flujos de trabajo empresariales

• Otros componentes empresariales

Diseño de Interfaz de Servicios

• Punto de entrada a implementación interna

• Fachada que expone Métodos

• Individual o Secuencial

• Contrato público

– Esquema de datos

– Seguridad, autenticación

– Proceso

Recomendaciones

• Límite de confianza de su Aplicación

• Que los cambios de funcionalidad no impliquen cambios de interfaz

• Diferentes usuarios, diferentes forma de consumo, diferentes interfaces, misma lógica

• Asmx, WSE, HTTP, Remoting, SOAP, MSMQ, WCF, TCP

Uso de Fachadas con Interfaces de Servicios

• Fachada:

– Autorización

– Auditoría

– Validaciones

– Usada por diferentes canales

Datos entre Niveles

• Windows Forms– Objetos, DataSet

• OOP– Objetos, DataSet Tipados

• ASP.NET– DataReader, DataSet, LinQ, XML + XSLT

• Listados– DataReader, DataSet, LinQ, XML + XSLT

• Binding– Objetos, DataSet, DataSet Tipados, XML, LinQ

Componentes de entidades empresariales personalizadas

• Clases Custom

• DTO (data transfer object)

• Representan 1 o mas tablas del modelo relacional

• Serializables

• No tienen comportamiento

• No acceden al almacenamiento de datos, ni manejan Tx

• No son obligatorios….

Capa de Acceso a Datos

Capa de Datos

• Determinar:

– Almacén de datos a utilizar

– Diseño de los componentes para acceder a los datos

– Formato de datos entre capas y la programación relacionada.

Componentes Lógicos de Acceso a Datos

• Abstraen la semántica del almacén de datos

• Sin estado

• Separan el procesamiento empresarial de la lógica de acceso a datos.

• CRUD de entidades empresariales

• Pueden utilizar componente de ayuda de acceso a datos (DAAB)

Funcionalidad de los componentes de lógica de acceso a datos

• Separar la lógica empresarial de los esquemas de almacenamiento

• Proveen un único acceso a datos

• Actúan en una tabla principal y sus relacionadas

• Pueden encapsular bloqueo pesimista

• Pueden implementar caché

Uso de los Componentes Lógicos de Acceso a Datos

• Exponen CRUD, paginación

• Usan un componente de ayuda de acceso a datos

• Se recomienda el uso de procedimientos almacenados

No deben

• Invocar a otros componentes lógicos de acceso a datos. Mas previsibles.

• Iniciar transacciones distribuídas.

• Mantener estado entre llamadas a métodos

Métodos que expone un componente lógico

• Administración de Entidades: CRUD

• Consulta de datos de solo lectura (listados)

• Acciones que actualizarán y devolverán datos

• Devolución de Metadatos

• Subconjunto de datos (paginación).

Recomendaciones

• Devuelva solo los datos necesarios

• Use y no abuse de los SP

• SP estándard: Insert, Update, Delete, Select (generadores de código)

• Interfaces coherentes para clientes diferentes: ASP.NET -> DataReader

• Encargarse del cifrado (si es necesario)

• Utilice Tx solo cuando las necesite

• Utilice componentes de ayuda de acceso a datos

Componente de Ayuda de Acceso a Datos

• DAAB

• Genérico, no conoce de entidades

• Abstrae la APIs de ADO.NET y sus versiones

• Buenas prácticas de acceso a Datos

• Disminuye el código repetitivo

• Administración la conexión

• Agnóstico del motor de Base de Datos

• Caché de Parámetros de SP

Integración con Servicios

• Utilizar el API adecuada de llamada

• Traducción entre formatos

• Mantener estado entre conversaciones de ejecución larga

• Se recomienda utilizar un componente de agente (Proxy)– Encapsula la comunicación

– Se pueden considerar como los componentes lógico de acceso a datos para los servicios.

Conclusión

• Arquitectura en el diseño

• Reutilización

• Futuro para el Sistema

– Nueva Funcionalidad mas fácil de implementar

– Escalabilidad

• Reglas claras para el Team de desarrollo.

• Utilice el sentido común al aplicar los conceptos

Referencias

• msmvps.com/blogs/cwalzer

• Msdn.microsoft.com/practices– Enterprise Solution Patterns Using Microsoft .NET

– Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios

– http://msdn.microsoft.com/es-es/library/ms954595.aspx• Patterns & practices Enterprise Library

– .NET Data Access Architecture Guide

– Exception Management Architecture Guide

Preguntas?

Muchas graciaspor su participación

Carlos Walzercarlos@walzer.com.ar

msmvps.com/blogs/cwalzer