SlideShare a Scribd company logo
1 of 5
ARQUITECTURA EN 2 CAPAS
Las aplicaciones web se modelan mediante lo que se conoce como modelo de capas, Una
capa representa un elemento que procesa o trata información.
Modelo de dos capas (Arquitectura lógica):
La información atraviesa dos capas entre la interfaz y la administración de los datos.
Una arquitectura en 2 capas distribuye la aplicación en dos componentes lógicos. Las
responsabilidades de cada componente hacen a las variantes de esta arquitectura.
Surge la arquitectura en 2 capas como consecuencia de la arquitectura cliente/servidor. Esta
topología permite distribuir la carga de la aplicación a dos computadores diferentes, lo que llevó
naturalmente a distribuir las responsabilidades de la misma a dos unidades lógicas.
Normalmente cuando se habla de aplicaciones de dos niveles se está haciendo referencia a una
aplicación donde el cliente mantiene la lógica de presentación, de negocio, y de acceso a los
datos, y el servidor únicamente gestiona los datos.
Funciones:
 Lógica de presentación.  P (Presentarlos adecuadamente a los usuarios)
Se encarga de la entrada y salida de la aplicación con el usuario. Sus principales tareas son:
obtener información del usuario, enviar la información del usuario a la lógica de negocio para su
procesamiento, recibir los resultados del procesamiento de la lógica de negocio y presentar estos
resultados al usuario.
 Lógica de negocio (o aplicación).  L (Presentarlos en forma acorde a la Log. De Neg.)
Se encarga de gestionar los datos a nivel de procesamiento. Actúa de puente entre el usuario y los
datos. Sus principales tareas son: recibir la entrada del nivel de presentación, interactuar con la
lógica de datos para ejecutar las reglas de negocio (business rules) que tiene que cumplir la
aplicación (facturación, cálculo de nóminas, control de inventario, etc.) y enviar el resultado del
procesamiento al nivel de presentación.
 Lógica de datos.  D (Datos persistentes)
Se encarga de gestionar los datos a nivel de almacenamiento. Sus principales tareas son:
almacenar los datos, recuperar los datos, mantener los datos y asegurar la integridad de los datos.
Arquitecturas:
1. P+L/D
Una primera variante es retirar el manejo de datos de la aplicación. Esto permite a varios clientes
utilizar el mismo juego de datos. P+L es una unidad lógica por sí, donde el manejo de interfaz de
usuario y el manejo de la lógica no se los distingue como módulos independientes. Típicamente
P+L se encuentra en el cliente, mientras que D se encuentra en el servidor. Un ejemplo de
aplicaciones con esta arquitectura es una aplicación que delega la persistencia a un manejador de
base de datos.
Datos distribuidos
Los datos son los que se distribuyen, por lo que la lógica de datos es lo que queda separada del
resto de la aplicación (Figura 3.6). Se puede dar de dos formas: ficheros distribuidos o bases de
datos distribuidas.
2. P/L+D
El hecho de tener la misma lógica en cada cliente permitió factorizarla, llevando la misma al
servidor.
Aquí la lógica de la aplicación se encuentra embebida al manejo de la persistencia de datos. En
este tipo de aplicaciones la lógica resuelve los problemas de persistencia encargándose ella
misma de dicha tarea, no necesariamente utilizando un manejador de base de datos, o
embebiendo toda la lógica de negocios en el mismo.
Presentación distribuida
El cliente sólo mantiene la presentación, el resto de la aplicación se ejecuta remotamente (Figura
3.4). La presentación distribuida, en su forma más simple, es una interfaz gráfica de usuario a la
que se le pueden acoplar controles de validación de datos, para evitar la validación de los mismos
en el servidor.
3. P+L/L+D
Una tercera variante es repartir la tarea de la lógica, una parte junto a la interfaz de usuario, y otro
junto al manejo de persistencia de datos.
Un ejemplo de aplicaciones con esta arquitectura son aplicaciones similares a las que tienen
arquitectura P+L/D, que tienen implementada parte de la lógica en procedimientos almacenados
en el manejador de la base de datos.
Aplicación distribuida
Es el modelo que proporciona máxima flexibilidad, puesto que permite tanto a servidor como a
cliente mantener la lógica de negocio realizando cada uno las funciones que le sean más propias,
bien por organización, o bien por mejora en el rendimiento del sistema (Figura 3.5).
Desventajas
Las limitaciones de este modelo son.
 Es difícilmente escalable
 Número de conexiones reducida: Las estaciones de trabajo pueden tener serias
restricciones de recursos.
 Alta carga de la red: dado que el procesamiento de los datos se realiza en el cliente, gran
cantidad de información debe ser transmitida desde el servidor.
 La flexibilidad es restringida
 La funcionalidad es limitada.

More Related Content

What's hot

Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
CristobalFicaV
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
aics-1986-13-saraguro
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de uso
Julio Pari
 
Manual tecnico y manual de usuario
Manual tecnico y manual de usuarioManual tecnico y manual de usuario
Manual tecnico y manual de usuario
D MT
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividad
Julio Pari
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
Sergio Sanchez
 

What's hot (20)

Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capas03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capas
 
Ensamblador y lenguaje c
Ensamblador y lenguaje cEnsamblador y lenguaje c
Ensamblador y lenguaje c
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Modelado basados en escenarios
Modelado basados en escenariosModelado basados en escenarios
Modelado basados en escenarios
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de uso
 
Manual tecnico y manual de usuario
Manual tecnico y manual de usuarioManual tecnico y manual de usuario
Manual tecnico y manual de usuario
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividad
 
Ads sistema-panaderia-ADS
Ads sistema-panaderia-ADSAds sistema-panaderia-ADS
Ads sistema-panaderia-ADS
 
Gestion entrada y salida
Gestion entrada y salidaGestion entrada y salida
Gestion entrada y salida
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
MetodologíAs Y Ciclos De Vida
MetodologíAs Y Ciclos De VidaMetodologíAs Y Ciclos De Vida
MetodologíAs Y Ciclos De Vida
 
Calidad De Software
Calidad De SoftwareCalidad De Software
Calidad De Software
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
 

Similar to 1.2 arquitectura en 2 capas

Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con access
univ of pamplona
 
A charla12 arq.3-capas
A charla12 arq.3-capasA charla12 arq.3-capas
A charla12 arq.3-capas
home
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
mi casa
 
Segunda sesion modulo 2 : Ing. Adriana Iglesias.
Segunda sesion modulo 2 : Ing. Adriana Iglesias.Segunda sesion modulo 2 : Ing. Adriana Iglesias.
Segunda sesion modulo 2 : Ing. Adriana Iglesias.
castlellanos
 
Monografia top sw
Monografia top swMonografia top sw
Monografia top sw
jamoca25
 
Arquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxArquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docx
William Martinez Perez
 
Programacion por capas
Programacion por capasProgramacion por capas
Programacion por capas
Josue Lopez
 
Arquitectura 2
Arquitectura 2Arquitectura 2
Arquitectura 2
bistasa
 
Desarrollo de aplicaciones de abd
Desarrollo de aplicaciones de abdDesarrollo de aplicaciones de abd
Desarrollo de aplicaciones de abd
Google
 

Similar to 1.2 arquitectura en 2 capas (20)

Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con access
 
A charla12 arq.3-capas
A charla12 arq.3-capasA charla12 arq.3-capas
A charla12 arq.3-capas
 
SISTEMA DE BASE DE DATOS
SISTEMA DE BASE DE DATOSSISTEMA DE BASE DE DATOS
SISTEMA DE BASE DE DATOS
 
Arquitectura en capas
Arquitectura en capasArquitectura en capas
Arquitectura en capas
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
N-CAPAS EN VISUAL NET
N-CAPAS EN VISUAL NETN-CAPAS EN VISUAL NET
N-CAPAS EN VISUAL NET
 
Segunda sesion modulo 2 : Ing. Adriana Iglesias.
Segunda sesion modulo 2 : Ing. Adriana Iglesias.Segunda sesion modulo 2 : Ing. Adriana Iglesias.
Segunda sesion modulo 2 : Ing. Adriana Iglesias.
 
Monografia top sw
Monografia top swMonografia top sw
Monografia top sw
 
3 capas
3 capas3 capas
3 capas
 
Arquitectura web
Arquitectura webArquitectura web
Arquitectura web
 
Aplicaciones informáticas
Aplicaciones informáticasAplicaciones informáticas
Aplicaciones informáticas
 
Arquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxArquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docx
 
Programacion por capas
Programacion por capasProgramacion por capas
Programacion por capas
 
Programación en capass
Programación en capassProgramación en capass
Programación en capass
 
Arquitectura 2
Arquitectura 2Arquitectura 2
Arquitectura 2
 
Arquitectura
ArquitecturaArquitectura
Arquitectura
 
Desarrollo de aplicaciones de abd
Desarrollo de aplicaciones de abdDesarrollo de aplicaciones de abd
Desarrollo de aplicaciones de abd
 
Programando en capas
Programando en capasProgramando en capas
Programando en capas
 
Programacion capas
Programacion capasProgramacion capas
Programacion capas
 
Arquitectura en Capas
Arquitectura en CapasArquitectura en Capas
Arquitectura en Capas
 

Recently uploaded

Recently uploaded (20)

Quimica Raymond Chang 12va Edicion___pdf
Quimica Raymond Chang 12va Edicion___pdfQuimica Raymond Chang 12va Edicion___pdf
Quimica Raymond Chang 12va Edicion___pdf
 
Propuesta para la creación de un Centro de Innovación para la Refundación ...
Propuesta para la creación de un Centro de Innovación para la Refundación ...Propuesta para la creación de un Centro de Innovación para la Refundación ...
Propuesta para la creación de un Centro de Innovación para la Refundación ...
 
PostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCDPostgreSQL on Kubernetes Using GitOps and ArgoCD
PostgreSQL on Kubernetes Using GitOps and ArgoCD
 
tema05 estabilidad en barras mecanicas.pdf
tema05 estabilidad en barras mecanicas.pdftema05 estabilidad en barras mecanicas.pdf
tema05 estabilidad en barras mecanicas.pdf
 
Falla de san andres y el gran cañon : enfoque integral
Falla de san andres y el gran cañon : enfoque integralFalla de san andres y el gran cañon : enfoque integral
Falla de san andres y el gran cañon : enfoque integral
 
introducción a las comunicaciones satelitales
introducción a las comunicaciones satelitalesintroducción a las comunicaciones satelitales
introducción a las comunicaciones satelitales
 
UNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotencialesUNIDAD 3 ELECTRODOS.pptx para biopotenciales
UNIDAD 3 ELECTRODOS.pptx para biopotenciales
 
Comite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptxComite Operativo Ciberseguridad 012020.pptx
Comite Operativo Ciberseguridad 012020.pptx
 
Sesión 02 TIPOS DE VALORIZACIONES CURSO Cersa
Sesión 02 TIPOS DE VALORIZACIONES CURSO CersaSesión 02 TIPOS DE VALORIZACIONES CURSO Cersa
Sesión 02 TIPOS DE VALORIZACIONES CURSO Cersa
 
nomenclatura de equipo electrico en subestaciones
nomenclatura de equipo electrico en subestacionesnomenclatura de equipo electrico en subestaciones
nomenclatura de equipo electrico en subestaciones
 
clasificasion de vias arteriales , vias locales
clasificasion de vias arteriales , vias localesclasificasion de vias arteriales , vias locales
clasificasion de vias arteriales , vias locales
 
Maquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdfMaquinaria Agricola utilizada en la produccion de Piña.pdf
Maquinaria Agricola utilizada en la produccion de Piña.pdf
 
Tinciones simples en el laboratorio de microbiología
Tinciones simples en el laboratorio de microbiologíaTinciones simples en el laboratorio de microbiología
Tinciones simples en el laboratorio de microbiología
 
Manual_Identificación_Geoformas_140627.pdf
Manual_Identificación_Geoformas_140627.pdfManual_Identificación_Geoformas_140627.pdf
Manual_Identificación_Geoformas_140627.pdf
 
Elaboración de la estructura del ADN y ARN en papel.pdf
Elaboración de la estructura del ADN y ARN en papel.pdfElaboración de la estructura del ADN y ARN en papel.pdf
Elaboración de la estructura del ADN y ARN en papel.pdf
 
INTEGRALES TRIPLES CLASE TEORICA Y PRÁCTICA
INTEGRALES TRIPLES CLASE TEORICA Y PRÁCTICAINTEGRALES TRIPLES CLASE TEORICA Y PRÁCTICA
INTEGRALES TRIPLES CLASE TEORICA Y PRÁCTICA
 
Reporte de simulación de flujo del agua en un volumen de control MNVA.pdf
Reporte de simulación de flujo del agua en un volumen de control MNVA.pdfReporte de simulación de flujo del agua en un volumen de control MNVA.pdf
Reporte de simulación de flujo del agua en un volumen de control MNVA.pdf
 
Ejemplos de cadenas de Markov - Ejercicios
Ejemplos de cadenas de Markov - EjerciciosEjemplos de cadenas de Markov - Ejercicios
Ejemplos de cadenas de Markov - Ejercicios
 
aCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.pptaCARGA y FUERZA UNI 19 marzo 2024-22.ppt
aCARGA y FUERZA UNI 19 marzo 2024-22.ppt
 
ECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdfECONOMIA APLICADA SEMANA 555555555544.pdf
ECONOMIA APLICADA SEMANA 555555555544.pdf
 

1.2 arquitectura en 2 capas

  • 1. ARQUITECTURA EN 2 CAPAS Las aplicaciones web se modelan mediante lo que se conoce como modelo de capas, Una capa representa un elemento que procesa o trata información. Modelo de dos capas (Arquitectura lógica): La información atraviesa dos capas entre la interfaz y la administración de los datos. Una arquitectura en 2 capas distribuye la aplicación en dos componentes lógicos. Las responsabilidades de cada componente hacen a las variantes de esta arquitectura. Surge la arquitectura en 2 capas como consecuencia de la arquitectura cliente/servidor. Esta topología permite distribuir la carga de la aplicación a dos computadores diferentes, lo que llevó naturalmente a distribuir las responsabilidades de la misma a dos unidades lógicas. Normalmente cuando se habla de aplicaciones de dos niveles se está haciendo referencia a una aplicación donde el cliente mantiene la lógica de presentación, de negocio, y de acceso a los datos, y el servidor únicamente gestiona los datos. Funciones:  Lógica de presentación.  P (Presentarlos adecuadamente a los usuarios) Se encarga de la entrada y salida de la aplicación con el usuario. Sus principales tareas son: obtener información del usuario, enviar la información del usuario a la lógica de negocio para su procesamiento, recibir los resultados del procesamiento de la lógica de negocio y presentar estos resultados al usuario.  Lógica de negocio (o aplicación).  L (Presentarlos en forma acorde a la Log. De Neg.) Se encarga de gestionar los datos a nivel de procesamiento. Actúa de puente entre el usuario y los datos. Sus principales tareas son: recibir la entrada del nivel de presentación, interactuar con la lógica de datos para ejecutar las reglas de negocio (business rules) que tiene que cumplir la aplicación (facturación, cálculo de nóminas, control de inventario, etc.) y enviar el resultado del procesamiento al nivel de presentación.
  • 2.  Lógica de datos.  D (Datos persistentes) Se encarga de gestionar los datos a nivel de almacenamiento. Sus principales tareas son: almacenar los datos, recuperar los datos, mantener los datos y asegurar la integridad de los datos. Arquitecturas: 1. P+L/D Una primera variante es retirar el manejo de datos de la aplicación. Esto permite a varios clientes utilizar el mismo juego de datos. P+L es una unidad lógica por sí, donde el manejo de interfaz de usuario y el manejo de la lógica no se los distingue como módulos independientes. Típicamente P+L se encuentra en el cliente, mientras que D se encuentra en el servidor. Un ejemplo de aplicaciones con esta arquitectura es una aplicación que delega la persistencia a un manejador de base de datos. Datos distribuidos Los datos son los que se distribuyen, por lo que la lógica de datos es lo que queda separada del resto de la aplicación (Figura 3.6). Se puede dar de dos formas: ficheros distribuidos o bases de datos distribuidas.
  • 3. 2. P/L+D El hecho de tener la misma lógica en cada cliente permitió factorizarla, llevando la misma al servidor. Aquí la lógica de la aplicación se encuentra embebida al manejo de la persistencia de datos. En este tipo de aplicaciones la lógica resuelve los problemas de persistencia encargándose ella misma de dicha tarea, no necesariamente utilizando un manejador de base de datos, o embebiendo toda la lógica de negocios en el mismo. Presentación distribuida El cliente sólo mantiene la presentación, el resto de la aplicación se ejecuta remotamente (Figura 3.4). La presentación distribuida, en su forma más simple, es una interfaz gráfica de usuario a la que se le pueden acoplar controles de validación de datos, para evitar la validación de los mismos en el servidor.
  • 4. 3. P+L/L+D Una tercera variante es repartir la tarea de la lógica, una parte junto a la interfaz de usuario, y otro junto al manejo de persistencia de datos. Un ejemplo de aplicaciones con esta arquitectura son aplicaciones similares a las que tienen arquitectura P+L/D, que tienen implementada parte de la lógica en procedimientos almacenados en el manejador de la base de datos. Aplicación distribuida Es el modelo que proporciona máxima flexibilidad, puesto que permite tanto a servidor como a cliente mantener la lógica de negocio realizando cada uno las funciones que le sean más propias, bien por organización, o bien por mejora en el rendimiento del sistema (Figura 3.5).
  • 5. Desventajas Las limitaciones de este modelo son.  Es difícilmente escalable  Número de conexiones reducida: Las estaciones de trabajo pueden tener serias restricciones de recursos.  Alta carga de la red: dado que el procesamiento de los datos se realiza en el cliente, gran cantidad de información debe ser transmitida desde el servidor.  La flexibilidad es restringida  La funcionalidad es limitada.