Vous êtes sur la page 1sur 37

Arquitectura de aplicaciones .NET

Arquitectura de aplicaciones .NET  Daniel A. Montero González  Consultor .NET
 Daniel A. Montero González  Consultor .NET
 Daniel A. Montero González
 Consultor .NET

Agenda

 Aclaraciones y expectativas  Aplicaciones n-capas  Aplicaciones monolíticas  Aplicaciones dos capas 
 Aclaraciones y expectativas
 Aplicaciones n-capas
 Aplicaciones monolíticas
 Aplicaciones dos capas
 Aplicaciones tres capas
 Reflexiones
 Entidades de negocio
 Consideraciones
 Guías de decisión
 Conclusiones

Aclaraciones y expectativas

 Aclaraciones  Nuestra visión e interpretación de la arquitectura propuesta  Nuestra experiencia 
 Aclaraciones
 Nuestra visión e interpretación de la
arquitectura propuesta
 Nuestra experiencia
 Nuestros resultados
 Expectativas
 Abrir sus mentes
 Entender el modelo propuesto
@
@

¿Esoterismo?

¿Esoterismo?  Componentes de IU  Componentes de negocio  Componentes de datos  Aplicaciones n-capas
¿Esoterismo?  Componentes de IU  Componentes de negocio  Componentes de datos  Aplicaciones n-capas
 Componentes de IU  Componentes de negocio  Componentes de datos
 Componentes de IU
 Componentes de negocio
 Componentes de datos

Aplicaciones n-capas

¿Esoterismo?  Componentes de IU  Componentes de negocio  Componentes de datos  Aplicaciones n-capas

Aplicación n-capas

Arquitectura monolítica  Toda la problemática se resuelve en un solo lugar  Formulario Windows
Arquitectura monolítica
 Toda la problemática se resuelve en un
solo lugar
 Formulario Windows o Web
 Lógica de presentación
 Despliegue de controles
 Reglas de negocio
 Toma de decisiones
 Acceso a datos
 Consultas, transacciones, eliminaciones

Demo 1.0

 Versión monolítica
 Versión monolítica

Ventajas y desventajas

 Ventajas  Rápido de programar, probar y funcionar  Buen rendimiento (*)  Desventajas
 Ventajas
 Rápido de programar, probar y funcionar
 Buen rendimiento (*)
 Desventajas
 Fuerte dependencia entre:
 Lógica de presentación
 Reglas de negocio
 Modelo de datos
 Nula reutilización y encapsulamiento
 Responsabilidades poco claras
 Complejos ciclos de mantención
@

Problemas a resolver

 ¿Cuál es la lógica de presentación?  ¿Dónde están las reglas de negocio? 
 ¿Cuál es la lógica de presentación?
 ¿Dónde están las reglas de negocio?
 ¿Cómo es el modelo de datos?
 ¿Qué sucede si modifico el modelo de datos?
 ¿Qué sucede si modifico el modelo de datos?

Aplicación n-capas

Arquitectura de dos capas  Independizo la presentación de la lógica negocio  Formulario Windows
Arquitectura de dos capas
 Independizo la presentación de la lógica
negocio
 Formulario Windows o Web
 Lógica de presentación
 Despliegue de controles
 Componentes de negocio
 Reglas de negocio
 Toma de decisiones
 Acceso a datos
 Consultas, transacciones, eliminaciones

Demo 2.0

 Versión dos capas
 Versión dos capas

Ventajas y desventajas

 Ventajas  Se independiza levemente la capa de presentación del modelo de datos 
 Ventajas
 Se independiza levemente la capa de
presentación del modelo de datos
 Encapsulo algo de funcionalidad
 Mejor reutilización código
 Mejor definición de responsabilidades, pero
aún no es suficiente

Ventajas y desventajas

 Desventajas  Aun depende mi capa de presentación del modelo de datos  Nombre
 Desventajas
 Aun depende mi capa de presentación del
modelo de datos
 Nombre de los campos
 Cantidad y tipo de parámetros
 Fuerte dependencia entre negocio y datos
 Baja leve en rendimiento (*)
 Generación de XML e interpretación del
mismo (posibles errores de parseo) (*)
 Mayor codificación
@
@

Problemas a resolver

 Debo parsear e interpretar algunos datos en la capa de presentación. ¿Por qué? 
 Debo parsear e interpretar algunos
datos en la capa de presentación. ¿Por
qué?
 ¿Dónde están las reglas de negocio?
 ¿Cómo es el modelo de datos?
 ¿Qué sucede si modifico el modelo de datos?
 ¿Qué sucede si modifico el modelo de
datos?

Aplicación n-capas

Arquitectura de tres capas  Independizo la presentación de la lógica negocio  Independizo la
Arquitectura de tres capas
 Independizo la presentación de la lógica
negocio
 Independizo la lógica de negocio del
modelo de datos
 Formulario Windows o Web
 Lógica de presentación
 Componentes de negocio
 Reglas de negocio
 Componentes de acceso a datos
 Acceso a datos

Demo 3.0

 Versión tres capas
 Versión tres capas

Ventajas y desventajas

 Ventajas  Mejora la independencia entre las capas  Encapsulo la funcionalidad  Mejora
 Ventajas
 Mejora la independencia entre las capas
 Encapsulo la funcionalidad
 Mejora la reutilización de código

Ventajas y desventajas

 Desventajas  Aun depende mi capa de presentación del modelo de datos  Nombre
 Desventajas
 Aun depende mi capa de presentación del
modelo de datos
 Nombre de los campos
 Cantidad y tipo de parámetros
 Baja leve en rendimiento (*)
 Generación de XML e interpretación del
mismo (posibles errores de parseo) (*)
 Requiere aún más codificación
@
@

Problemas a resolver

 Eliminar dependencia de:  Nombre de los campos  Cantidad y tipo de parámetros
 Eliminar dependencia de:
 Nombre de los campos
 Cantidad y tipo de parámetros
 Eliminar el parseo de datos
 ¿Qué sucede si modifico el modelo de datos?
 ¿Qué sucede si modifico el modelo de
datos?
@
@

Reflexionando en el problema

 Todos los parámetros de las funciones representan algo  ¿Qué representan?  ¿Al usuario?
 Todos los parámetros de las funciones
representan algo
 ¿Qué representan?
 ¿Al usuario?
@
@

Entidades de negocio

 Representan entidades de los procesos de negocio  Usuario  Orden de compra 
 Representan entidades de los procesos
de negocio
 Usuario
 Orden de compra
 No contienen lógica, solo datos
 Una entidad puede estar compuesta de
otras entidades (OOP)
 Las distintas capas se comunican a
través de entidades de negocio en un
alto porcentaje

Demo 4.0

 Versión con entidades de negocio
 Versión con entidades de negocio
 ¿Vale la pena tanto trabajo?
 ¿Vale la pena tanto trabajo?
@
@

¿Esoterismo?

¿Esoterismo?
¿Esoterismo?
¿Esoterismo?
¿Esoterismo?
¿Esoterismo?

Ventajas y desventajas

 Ventajas iniciales. Demo 1.0  Rápido de programar, probar y funcionar  Buen rendimiento
 Ventajas iniciales. Demo 1.0
 Rápido de programar, probar y funcionar
 Buen rendimiento (*)
 Ventajas finales. Demo 4.0
 Alta independencia entre las capas
 Alta reutilización de código
 Encapsulado de toda la funcionalidad
 Definición de completa de las
responsabilidades
 Posibilidad de ejecutar pruebas unitarias

Ventajas y desventajas

 Desventajas iniciales. Demo 1.0  Fuerte dependencia entre:  Lógica de presentación  Reglas
 Desventajas iniciales. Demo 1.0
 Fuerte dependencia entre:
 Lógica de presentación
 Reglas de negocio
 Modelo de datos
 Nula reutilización y encapsulamiento
 Responsabilidades poco claras
 Complejos ciclos de mantención
 Desventajas finales. Demo 4.0
 Requiere mucha más codificación que la versión
monolítica
 Baja en el rendimiento comparado con las
@
anteriores (*)

¿Como se representan las entidades de negocio?

¿Como se representan las entidades de negocio?  XML  Dataset, tipificado o no  Clases
 XML  Dataset, tipificado o no  Clases VB o C#
 XML
 Dataset, tipificado o no
 Clases VB o C#

Utilizando XML

 Ventajas  Baja relación entre capas  Implementar colecciones  Serialización automática  Desventajas
 Ventajas
 Baja relación entre capas
 Implementar colecciones
 Serialización automática
 Desventajas
 Parseo de string (lento)
 Uso ineficiente de memoria
 Posibles errores al parsear, configuración
Regional, ausencia de datos
 No es posible mantener información
privada de la entidad
@

DataSets

 Ventajas  Datasets tipificados soportan validación  Implementar colecciones  Baja relación entre capas
 Ventajas
 Datasets tipificados soportan validación
 Implementar colecciones
 Baja relación entre capas
 Serialización automática
 Permite representar varias entidades
 Lee y Escribe XML
 Desventajas
 Creación y traspaso costoso
 Código complicado de leer

(string) dsCliente.Tables[“Clientes”].Rows(0)[“Nombre”]

 Se trata de un objeto más pesado  No es posible mantener información privada
 Se trata de un objeto más pesado
 No es posible mantener información privada de la
entidad

Clases VB o C#

 Ventajas  Código legible  Funcionalidad encapsulada  Soporte de campos privados  Baja
 Ventajas
 Código legible
 Funcionalidad encapsulada
 Soporte de campos privados
 Baja relación entre capas
 Implementar colecciones
 Crear validaciones “astutas”
 Serialización binaria automática
 Desventajas
 El llamante debe conocer la entidad a recibir
(integraciones)
 Serialización xml manual
 Manejo de relaciones de forma manual
@

¿Cuál elegir?

 Depende de la necesidad de cada uno
 Depende de la necesidad de cada uno

Consideraciones

 ¿Es necesario ordenar o buscar sobre registros de entidades?  ¿Es necesario hacer bind
 ¿Es necesario ordenar o buscar sobre
registros de entidades?
 ¿Es necesario hacer bind sobre
controles (textbox, dropdownlist)?
 ¿Serán accedidas local o remotamente?
 ¿Serán usadas por web services?

Guías de decisión

 Manteniendo pocos formatos de datos se obtiene mejor rendimiento y se facilita la mantención
 Manteniendo pocos formatos de datos
se obtiene mejor rendimiento y se
facilita la mantención a futuro
 Evitar transformaciones de datos
 El formato de datos dependerá de los
requerimientos de la aplicación
 No existe una forma universal de
representación de datos
@
@

Guías de decisión

 Tratar de diseñar usando formatos comunes (dataset, xml)  Considerar la funcionalidad y flexibilidad
 Tratar de diseñar usando formatos
comunes (dataset, xml)
 Considerar la funcionalidad y
flexibilidad de los datasets
 La creación de clases incrementa el
costo de desarrollo
 Las interfaces gordas son preferidas en
aplicaciones que cruzan procesos o
máquinas

Guías de decisión

 Aplicaciones con ordenamiento, búsquedas y bind  Dataset, XML en menor medida  Instancias
 Aplicaciones con ordenamiento,
búsquedas y bind
 Dataset, XML en menor medida
 Instancias de datos
 Clases, el resto en menor medida
 Trabajar en forma de OOP
 Clases
@
@

Controles de usuario

 ¿Controles de usuarios y entidades?  Pueden recibir y retornar entidades de negocio en
 ¿Controles de usuarios y entidades?
 Pueden recibir y retornar entidades de
negocio en nuestras interfaces
 Demo con controles de usuario
@@
@@

Conclusión

 Diseñar a lo menos con tres capas  Buscar la mayor independencia entre las
 Diseñar a lo menos con tres capas
 Buscar la mayor independencia entre
las capas
 Respetar la visibilidad entre las capas
 Respetar la visibilidad en la capa de
datos
 Definir las entidades de negocio

Información adicional

 Documento original  http://msdn.microsoft.com/library/en-us/dnbda/html/boagag.asp
 Documento original
http://msdn.microsoft.com/library/en-us/dnbda/html/boagag.asp