You are on page 1of 5

ARQUITECTURA EN CAPAS

miércoles, 10 de agosto de 2011
ARQUITECTURA 3 CAPAS PROGRAMACIÓN POR CAPAS
Es un estilo de programación, su objetivo primordial es la separación de la capa de presentación, capa de
negocio y la capa de datos.

La arquitectura de una aplicación es la vista conceptual de la estructura de esta.
Toda aplicación contiene código de presentación, código de procesamiento de datos
y código de almacenamiento de datos. La arquitectura de las aplicaciones difieren
según como esta distribuido este código.
Windows DNA presenta una arquitectura de aplicaciones de tres-capas, basadas en
componentes. La meta de DNA es unificar las aplicaciones para PC, las aplicaciones
cliente / servidor y las aplicaciones basadas en la Web, lo cual es posible para
aplicaciones
de
cualquier
tamaño.
En nuestros días mucha información importante está almacenada en aplicaciones
como sistemas de correo electrónico, y aún más recientemente en servicios de
directorio. Microsoft habla sobre Universal Data Access (Acceso Universal a Datos)
como una serie de manejadores e interfaces diseñadas para proveer una forma de
conseguir acceder a este tipo de almacenamientos y más aún a datos como
archivos de formato especiales, datos de posición geoespacial, datos científicos no
estándar, etc. Los servicios son puestos en la red y operan de manera cooperativa
para dar soporte a uno o más procesos de negocios. En este modelo, una aplicación
se convierte en un conjunto de servicios de usuario, negocios y datos que satisface
las necesidades de los procesos de negocios o procesa su soporte. Como los
servicios están diseñados para el uso general y siguen lineamientos de interfaz
publicados, pueden ser reutilizados y compartidos entre múltiples aplicaciones. La
arquitectura DNA de tres capas como se muestra en el grafico cuenta con servicios
específicos en cada capa que se comunican entre si mediante COM (Component
Object Model)

Redes de Computadores. El ejemplo más conocido es el de los protocolos en Redes de Computadores. es decir para satisfacer una solicitud a una capa i+2. La capa i+1 puede juntar varios eventos antes de notificar a su vez an elemento de la capa i+2. 3. Arquitectura bidireccional de capas En su forma más común involucra dos pilas de N capas que se comunican entre si.). Arquitectura top-down de capas: Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si. Arquitectura bottom-up de capas: Cada elemento de una capa i puede notificar a elementos de la capa superior i+1 de que ha ocurrido algún evento de interés (ej. Nos limitaremos a manejar la noción de arquitectura como una forma de estructurar los elementos de un software. ésta requiere enviar varias solicitudes a la capa i+1. 2. manejadores de dispositivos). Una arquitectura bottom-up tambien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i. cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y así sucesivamente.Arquitectura de Capas Preguntar qué conocen por arquitectura de capas (en Sistemas de Operación. Típicamente se produce una cascada de solicitudes.. pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes: 1. Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores.. .

se deben tomar en cuenta los siguientes factores: 1. 5. abandonar. . Determinar el número de capas En términos simplistas. Típicamente las capas más internas ofrecen menos servicios. a más capas más flexibilidad pero menor desempeño. Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de línea. [Discutir] 3.Al implementar una arquitectura top-down de capas. menor dependencia externa sobre la estructura de una capa. 2. En un modelo puro "empujado" (push). Esto ayuda la reutilización de capas ("pirámide invertida de reuso"). usar una fuente alterna?). de acuerdo con el tipo de servicio solicitado. Estructura interna de cada capa. ¿Cuánta información pasar de una capa a otra? Tomemos el caso de la arquitectura top-down. El grado de encapsulamiento de las capas. la capa superior está obligada a enviarle toda la información que pueda llegar a hacerle falta a la capa inferior en la solicitud. 6. Es muy posible que. la capa inferior requiera una cantidad de información variable. ¿Qué se hace: reintentar. 4. A mayor encapsulamiento. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una capa? Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información.

"halado" (pull o por demanda). aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programación. pero generalmente abstrayendo el tipo de error para que sea comprensible en término de los servicios de la capa superior. Este patrón de diseño lo estudiaremos más adelante. 7. si esto no es posible. La solución la proporciona el patrón Editorial-Suscriptor (PublishSubscribe) que encapsula la idea del callback.En el modelo contrario. o Trabajo innecesario por parte de capas más internas o redundante entre varias capas. la capa inferior solicita mayor información sólo si le hace falta --¿pero de quién la pida? El modelo de solicitudes top-down presupone un invocador anónimo y un invocado conocido. o Facilita la estandarización o Dependencias se limitan a intra-capa o Contención de cambios a una o pocas capas  Desventajas o A veces no se logra la contención del cambio y se requiere una cascada de cambios en varias capas. Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura de capas ya las hemos mencionado [dejar que los estudiantes las resuman]:  Ventajas o Reutilización de capas. Diseñe la estrategia de manejo de errores. o Pérdida de eficiencia. dejar que lo resuelva la capa más arriba. o Dificultad de diseñar correctamente la granularidad de las capas. Típicamente se recomienda manejar el error en el nivel que lo descubrió. Este es un aspecto que es frecuentemente obviado. Arquitectura de capas en Sistemas de Información .

 Arquitectura de cuatro capas. Las diferencias entre estas arquitecturas las pospondremos hasta que nos corresponda estudiar el proceso de diseño de un software. Por los momentos. donde las capas a veces reciben el nombre de niveles (en Inglés tiers):  Arquitectura de dos capas.Existen tres propuestas de arquitecturas de capas para Sistemas de Información.  Arquitectura de tres capas. . seguiremos RPM en presuponer que apuntamos a una arquitectura de tres capas.