Arquitectura Tcnica

1
Arquitectura Técnica

• Conceptos generales para desarrollo de
  aplicaciones sobre plataformas .NET

2003, León E. Welicki
2
Agenda

• 1. Fundamentos
• 2. Definición de las capas
• 3. Errores
• 4. Conceptos Generales
• 5. Contras y Pros

3
1. Fundamentos

• Objetivos
• Bases de la Arquitectura
• Esquema Conceptual
• Niveles de Abstracción
• Diagrama de Arquitectura General

4
Objetivos

• Objetivos
• Brindar una infraestructura común y consistente
  para desarrollar aplicaciones en forma rápida y
  eficiente, sobre una serie de servicios y
  características estándar.
• Promover la reutilización de componentes.
• Desacoplar las funciones de las aplicaciones en
  distintos niveles de abstracción buscando máxima
  cohesión y mínimo acomplamiento.

5
Bases de la Arquitectura

• Basada en conceptos de orientación a objetos.
• Basada en el concepto de n-capas.
• Cada capa realiza funciones en distintos niveles
  de abstracción.
• Las capas están desacopladas.
• Control robusto de errores en las capas
  inferiores.
• Estandarización de funciones rutinarias comunes a
  todas las aplicaciones.

6
Esquema Conceptual
Fuentes de Datos Repositorios de información
persistente. Estos repositorios son
independientes del sistema y pueden ser Oracle,
Sql Server, Xml, etc.Son elementos externos a
nuestra arquitectura.
Oracle
Access
Xml
Acceso Físico a Datos conjunto de componentes
que exponen funcionalidades relacionadas con las
fuentes de datos.
Acceso Físico a Datos
Acceso Lógico a Datos conjunto de componentes
que exponen funcionalidades relacionadas con
entidades de las fuentes de datos. Utilizan la
capa de acceso a físico para comunicarse con lo
repositorios
Acceso Lógico a Datos
Lógica de negocios implementa la lógica de
negocios particular de una aplicación. Utiliza
objetos de la subcapa de acceso lógico a datos
para manejo de la persistencia.
Lógica de Negocios
App. Winforms
ClienteClientes de las aplicaciones. Puede ser
otro objeto de negocios, una pagina aspx, una
aplicación winforms o cualquier entidad capaz de
utilizar objetos de .net. Son elementos externos
a nuestra arquitectura.
Página aspx
Objetos .net
7
Esquema Conceptual

• Elementos endógenos
• Subcapa de acceso físico a datos
• Subcapa de acceso lógico a datos
• Subcapa de negocios
• Elementos exógenos
• Fuentes de datos
• Clientes

8
Niveles de Abstracción (i)

• Los objetos de cada capa manejan un nivel
  distinto de abstracción.
• Cuanto más cercana está la capa al cliente, menos
  detalles se conocen sobre el soporte de datos.
• Cada capa tiene un foco particular de interés.
• Ejemplo en la app de organigramas
• Acceso Físico OleDb
• Acceso Lógico Sql
• Lógica de negocios c, objetos .net.

9
Niveles de Abstracción (ii)
Oracle
Access
Xml
Acceso Físico a Datos OleDb, Odbc, XmlDom,
etc. Maneja protocolos de bajo nivel de acceso a
datos (a traves de objetos del .Net Framework).
Acceso Físico a Datos
Acceso Lógico a Datos Sql, Xpath / Xquery,
etc. Lenguajes particulares de acceso a los
datos. No conoce detalles sobre el protocolo
utilizado para recuperar los datos ni sobre el
repositorio físico.
Acceso Lógico a Datos
Lógica de Negocios
Lógica de negocios c, vb.net, etc. Implementa
la lógica de negocios independientemente del
soporte de datos. No conoce detalles de SQL ni
protocolos de comunicación.
App. Winforms
Página aspx
Objetos .net
10
Diagrama de Arquitectura General
Subcapa de Acceso Físico a Datos (namespace util)
cOleDb
cOracle
cOdbc
cDirectory
IDataAccess (interface)
Subcapa de Acceso Lógico a Datos (namespace
DBProxy)
cDBProxyA
cDBProxyB
cDBProxyC
cDBProxyD
En este caso, cada objeto debe gestionar sus
excepciones y su mecanismo de logging.
cObject1
cObject2
cObject3
Subcapa de Lógica de Negocios (namespace Business)
Cliente de los objetos de negocios (pueden ser
objetos de presentacion, otros objetos de
negocios, otra aplicación, etc)
11
2. Definición de las Capas

• Fuentes de Datos
• Acceso Físico a Datos
• Acceso Lógico a Datos
• Lógica de Negocios

12
Fuentes de Datos

• Son fuentes de datos heterogéneas.
• Pueden tomarse como un factor exógeno a nuestro
  modelo.
• A modo general, se puede decir que esta capa
  puede incluir cualquier fuente de datos que pueda
  ser explotada a través de los protocolos
  estándares de acceso (OleDb, ODBC, LDAP).
• Para el caso particular de LDAP, la interface
  IDataAcess puede no ser el modo mas adecuado
  acceso.

13
Acceso Físico a Datos (i)

• Objetivo
• Exponer un conjunto de objetos que permitan el
  acceso y la manipulación de información en una
  fuente de datos específica.
• Este conjunto de objetos expone una interface
  única, estableciendo un patrón semántico
  unificado para acceder a los datos.
• Esto último permite abstraer el usufructo de una
  fuete de datos del protocolo de acceso y su
  organización.

14
Acceso Físico a Datos (ii)

• Esta capa es la que realiza el acceso a los datos
  a mas bajo nivel.
• Para cada caso particular implementa el protocolo
  apropiado (especialización).
• Esta compuesta por una serie de clases que
  implementan la interface de acceso a datos
  IDataAccess.
• Todas las clases de esta capa exponen la misma
  interface, pero su comportamiento interno puede
  ser muy diferente.

15
Acceso Físico a Datos (iii)

• Cada clase de acceso a datos debe gestionar las
  excepciones que se produzcan durante su
  ejecución.
• Ante un error, devuelven la excepción
  DAException.
• Cuando se dispara una excepción DAException, se
  registra en un fichero de log de errores de
  acceso físico a datos.

16
Acceso Lógico a Datos (i)

• Objetivos
• Manejo de la persistencia de entidades lógicas de
  datos (tablas, vistas, relaciones, etc).
• Brindar un nivel mayor de abstracción a los
  objetos de negocios.
• Centralizar y representar el conocimiento de una
  entidad lógica en objetos con comportamiento
  estandarizado.
• Promover mayor reutilización.
• Brindar un conjunto de servicios de acceso lógico
  a datos consistentes y normalizados.

17
Acceso Lógico a Datos (ii)

• Encapsulan la persistencia de elementos
  residentes en las fuentes de datos.
• Funcionan como proxies sobre entidades residentes
  en fuentes de datos.
• La relacion de encapsulamiento no debe ser
  necesariamente 1 objeto, 1 tabla.
• Conocen la interface IDataAccess.

18
Acceso Lógico a Datos (iii)

• Ante un error, disparan una excepción
  DBProxyError.
• Esta excepcion se logea automaticamente en un log
  de errores de acceso lógico a datos.

19
Lógica de Negocios (i)

• Objetivos
• Implementar la lógica de negocios de la
  aplicación, idependientemente del soporte de
  datos y los protocolos necesarios para su
  explotación.
• Separar la lógica de negocios de los detalles de
  implementación.

20
Lógica de Negocios (ii)

• Independencia de la lógica de negocios (motivo
  principal de la aplicación) del soporte de datos.
• La lógica de negocios no está mezclada con los
  detalles de implantación.
• Esto hace que las aplicaciones sean más
  mantenibles.
• Mayor cohesión (cohesión funcional).
• Brinda mayor reusabilidad.

21
3. Errores

• Premisas
• Niveles de Errores
• Errores de Acceso

22
Premisas (i)

• Mostrar el error apropiado al cliente
  apropiado.
• Tener trazabilidad e información completa de un
  error brinda más herramientas para solucionar una
  incidencia.
• Cada capa registra sus errores a distintos
  niveles.
• Las capas de acceso a datos tienen repositorios
  propios de registro de situaciones de excepción
  (sus logs).

23
Premisas (ii)

• Los errores en la capa de datos se gestionaran
  utilizando el mecanismo de control estructurado
  de excepciones try...catch.
• En las capas de acceso a datos se deben controlar
  todas las posibles situaciones de excepción.
• Dicho control estará estandarizado.
• Para las capas de lógica de negocios, se propone
  también el enfoque estructurado.

24
Niveles de Errores

• Acceso Físico
• Errores de acceso físico propios de los
  protocolos utilizados. Son errores de bajo nivel
  vinculados a problemas con la fuente de datos
  OleDb, ADO.NET, Odbc, XmlParseError, etc.
• Acceso Lógico
• Acceso Lógico errores de Sql, Xpath.
• EjemplosSql mal formado, Xpath mal formado, etc.
• Objetos de negocios
• Errores propios del negocio. Pueden ser
  validaciones de datos, reglas particulares, etc.

25
Niveles de Errores (ii)

• Los errores de acceso a datos, tanto en la capa
  física como en la capa lógica están dados por los
  protocolos y el lenguaje particular de acceso
  utilizado. Esto implica que siguen una
  estandarización ímplicita, inherente a sus
  elementos componentes.
• Los errores de lógica de negocio no siguen ningún
  tipo de estandarización. Son determinados por la
  aplicación y diseñados a tales efectos.

26
Errores de Acceso (i)

• Las capas de acceso a datos, tanto física como
  lógica deben implementar el control de errores
  completo, registrando la excepción en un log y
  disparando hacia arriba la excepción apropiada.
• Acceso Físico
• Excepción DAException
• Log app_name.DA.log
• Acceso Lógico
• Excepción DBProxyException
• Log app_name.DBProxy.log

27
Errores de Acceso (ii)

• El registro y disparo de excepciones mencionado
  en el punto anterior deben ser implementados
  completamente por cada clase.
• Esto implica que estas tareas sean parte del
  desarrollo de una clase de acceso a datos.

28
4. Conceptos Generales

• Frecuencia de Desarrollo
• Catálogos
• Flexibilidad

29
Frecuencia de Desarrollo

• Cada tipo de componente tendrá una distinta
  frecuencia de desarrollo.
• Con esto nos referimos a la necesidad de que sea
  desarrollado para un proyecto particular.
• Acceso físico sólo ante la necesidad de acceder
  a una nueva fuente de datos o de utilizar un
  nuevo protocolo de acceso para una fuente
  existente.
• Acceso lógico sólo ante la necesidad de acceder
  a una entidad de una fuente de datos para la que
  no exista un objeto a tales efectos.
• Objetos de negocios se deben desarrollar para
  cada aplicación. Son la razón de ser de las
  aplicaciones.

30
Catálogos

• Para promover y ayudar a la reutilización,
  existirán catálogos de componentes.
• Estos catálogos expondrán las funcionalidades
  existentes para que puedan ser reutilizadas por
  otras aplicaciones.
• Catálogo de Objetos de Acceso Físico a Datos.
• Catálogo de Objetos de Acceso Lógico a Datos.
• Catálogo de Objetos de Negocios.
• Los catálogos se generarán con ayuda de Visual
  Studio .net (comentarios Xml).

31
Catálogos

• Cada aplicación debe exponer su propio catálogo.
• De esta manera, el responsable de la aplicación
  es responsable del mantenimiento del catálogo.

32
Flexibilidad (i)

• La arquitectura permite cierta flexibilidad para
  el desarrollo.
• De esta manera, en casos muy particulares se
  pueden saltear capas, aunque esta no es una
  práctica recomendada.
• Ejemplo saltear la capa de acceso lógico a datos
  y crear objetos que implementen directamente las
  consultas sql utilizando objetos de acceso
  físico.
• En caso de saltearse una capa o más capas, se
  debe documentar la situación.

33
Flexibilidad (ii)

• Es importante tener en cuenta que al saltear las
  capas se pierden los siguientes beneficios
• Separación de los niveles de abstracción
• Necesidad de registrar y disparar errores en un
  contexto no apropiado (logear excepciones de
  acceso lógico en la capa de negocios).
• Dificulta la reutilización
• Una sentencia Sql o una función codificados en
  una página no pueden ser reutilizados por otros
  objetos.

34
Servicios Generales

• cSessionTracker
• Permite monitorear el inicio y el final de una
  session HTTP
• cLog
• Logging de situaciones de excepción

35
Ejemplo de Interacción
cPuesto
cDBProxyPuesto
cDbOleDb
Oracle
Load(idPuesto)
Read()
getReader(sSql)
Api de OleDb
OleDbDataReader (o la interface IDataReader)
Datos
Datos del puesto
Este bloque se incluye sólo para mostrar el flujo
completo. No debería estar en el diagrama real.
Puesto
36
Contras y Pros

• Contras
• Pros

37
Contras

• Algunos procesos son más lentos con esta
  implementación, ya que involucra mas capas.
• Por ejemplo, no hay cabida para la página que
  recupera un sql y lo recorre, todo esto desde la
  pagina o para la que hacer inserts, deletes, etc.
• Hay que crear el objeto de acceso lógico a datos,
  que crea al objeto de acceso físico a datos, etc
• Requiere más objetos para realizar una tarea
  determinada.
• Es más compleja que el enfoque de todo el código
  en páginas asp.

38
Contras (ii)

• En algunos casos, existen situaciones que se
  podrían solucionar con un simple SQL con varios
  joins antes que con tantos objetos.
• Hay que pensar en el futuro antes de desarollar
  una aplicación.
• Hay que utilizar componentes que existan, cuando
  hacer queries para cada situación puede ser mas
  rápido.
• Si falla una clase de acceso a datos, fallan
  todas las aplicaciones que la utilizan.

39
Pros

• Elimina la lógica de las páginas, permitiendo
  mayor reutilización.
• Base común para desarrollo de aplicaciones.
• Una funcionalidad se realiza en una y sólo una
  clase.
• Las aplicaciones son más prolijas, entendibles y
  mantenibles.
• Separation of concerns cada capa se ocupa de una
  tarea específica.
• Aprovecha mejor la potencia del entorno .NET.

40
Pros (ii)

• Posibilidad de catalogar todas las
  funcionalidades disponibles. Con el enfoque
  chapuza de código en las páginas se hace más
  difícil la catalogación y compartimiento de
  servicios.
• A medida que la cantidad de objetos de
  infraestructura crecen, se convierten en parte
  del repositorio de objetos reutilizables por el
  resto de la aplicación.
• Estandarización del control de errores en las
  capas de infraestructura.

41
Pros (iii)

• Posibilidad de modificar la implementación de una
  capa sin desestabilizar al sistema.
• Ejemplo 1 Ante un mejor método de acceso a
  datos, puedo crear un nuevo objeto de acceso
  físico o modificar el método apropiado en el
  objeto existente.
• Ejemplo 2 Si la validación de empleados se
  realiza en otra tabla, cambio el objeto proxy de
  acceso a los datos de los empleados.
• When quality is pursued, productivity follows
• K. Fujino, Vice President of NEC Corporation's
  CC Software Development Group

42
Citas

• By itself, reusability also helps if you are
  able to reuse component libraries produced and
  (presumably) validated by a reputable outside
  source, rather than developing your own solution
  for every single problem you encounter, you can
  start trusting part of the software no less than
  you trust the machine on which it runs. In
  effect, the reusable libraries become part of the
  "hardware-software machine" (hardware, operating
  system, compiler).
• In software development, reliability should be
  built-in, not an afterthought.
• Ambas citas de Bertrand Meyer, de Building bug
  free O-O software
• http//archive.eiffel.com/doc/manuals/technology/
  contract/

43

• Fin