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.