Programación en capas

Programación: Código máquina compilado e interpretado

directamente desde el núcleo del sistema o desde un script
(Código fuente interpretado), un conjunto concreto de
instrucciones que una computadora puede ejecutar. El programa
se escribe en un lenguaje de programación (conjunto de reglas
sintácticas y semánticas que definen su estructura y el significado
de sus elementos), aunque también se pueda escribir directamente
en lenguaje de Maquina (líneas de instrucciones de programas 0 y 1
o de caracteres hexadecimales), con cierta dificultad.

¿Cuantas capas existen para programar?

En la actualidad Se han propuesto diversas técnicas de

programación, cuyo objetivo es mejorar tanto el proceso de
creación de software como su mantenimiento. Entre ellas se
pueden mencionar las programaciones lineal, estructurada,
modular y orientada a objetos. Pero la programación en capas es
el mejor método para la facilidad de el programador por este
motivo existen n-capas pero El diseño más en boga actualmente es
el diseño en tres niveles (o en tres capas).
Programación en 3 capas o Three-Tier: es un estilo de
programación en la que el objetivo primordial es la separación de
la lógica de negocios de la lógica de diseño, un ejemplo básico de
esto es separar la capa de datos de la capa de presentación al
usuario. La programación en capas es la técnica más efectiva en
aplicaciones empresariales, debido a la fácil administración que
implica el dividir los componentes de la aplicación en capas y la
rapidez que esto implica en programas orientados a Cliente-
Servidor. Esta arquitectura consiste en dividir los componentes
primarios de la aplicación, programarlos por separado y después
unirlos en tiempo de ejecución

Definición: Una capa representa un elemento del sistema que

procesa o trata la información.

Características: Una capa puede residir (se ejecuta) en una

maquina diferente o en diferentes espacios o entornos de procesos
dentro de la misma maquina.
Diseñando Aplicaciones Distribuidas.

El diseño de aplicaciones modernas involucra la división de una

aplicación en múltiples capas; la interfase de usuario, la capa
media de objetos de negocios, y la capa de acceso a datos. Puede
ser útil identificar los tipos de procesamiento que podemos esperar
que una aplicación realice. Muchas aplicaciones pueden, al menos,
hacer lo siguiente:

• Cálculos u otros procesos de negocios.

• Ejecución de reglas de negocios.
• Validación de datos relacionados al negocio.
• Manipulación de datos.
• Ejecución de las reglas de datos relacional.
• Interactuar con aplicaciones externas o servicios.
• Interactuar con otros usuarios.

Nosotros podemos tomar estos tipos de servicios y generalizarlos

dentro de los tres grupos o capas que a continuación se resumen:

• Interfase de usuario (Capa de Presentación)

o Interactuar con otros usuarios.
o Interactuar con aplicaciones externas o servicios.
 • Procesos de negocios (Capa de Negocios)
o Cálculos u otros procesos de negocios.
o Ejecución de reglas de negocios.
o Validación de datos relacionados al negocio.

• Procesos de datos (Capa de Servicios de Datos).

o Manipulación de datos.
o Ejecución de las reglas de datos relacional.

La división de estos procesos de aplicaciones y su distribución

entre diferentes procesos cliente/servidor es conocido como
Procesamiento Distribuido. Generalizando estos procesos dentro
de estas tres categorías o capas es una distribución lógica y no
refleja necesariamente alguna opción de diseño físico sobre
computadoras, terminales u otros equipos. Usted puede desarrollar
una aplicación cliente/servidor distribuida basada sobre estas tres
capas de Presentación, Lógica de Negocios y Servicios de Datos y
tener la aplicación entera corriendo sobre una simple
computadora. Alternativamente, usted puede esparcir estas tres
capas a través de un gran número de diferentes computadoras
sobre una red. De cualquier forma usted ha desarrollado una
aplicación cliente/servidor de tres capas.
 Capas o niveles.

1 Capa de presentación (IU) : La capa de Presentación provee su

aplicación con una interfase de usuario (IU). Aquí es donde su
aplicación presenta información a los usuarios y acepta entradas o
respuestas del usuario para usar su programa. Idealmente, la IU no
desarrolla ningún procesamiento de negocios o reglas de validación
de negocios. Por el contrario, la IU debería relegar sobre la capa
de negocios para manipular estos asuntos. Esto es importante,
especialmente hoy en día, debido a que es muy común para una
aplicación tener múltiples IU, o para sus clientes o usuarios, que le
solicitan que elimine una IU y la remplace con otra. Por ejemplo,
usted puede desarrollar una aplicación Win32 (un programa en
Visual Basic) y entonces solicitársele remplazarla con una página
HTLM., quizás usando tecnología ASP(Active Server Pages creación
de páginas dinámicas del lado del servidor).

Una de las mayores dificultades y factores importantes cuando

desarrollamos aplicaciones cliente/servidor es mantener una
separación completa entre la presentación, la lógica de negocios y
los servicios de datos. Es muy tentador para los desarrolladores
mezclar una o más capas; poniendo alguna validación u otro
proceso de negocios dentro de la capa de presentación en vez de
en la capa de negocios.
Comprende las responsabilidades de lógica de presentación:

• Navegabilidad del sistema

• Validación de datos de entrada

• Formateo de los datos de salida

• Internacionalización

• Reenderezado de presentación

• Etc.

Funciones de la capa de Presentación:

• Recoger la información del Usuario.

• Enviar esta información a la Capa de Negocios.

• Recoger resultados de la Capa de Negocios

• Presentar los resultados al usuario.

2 Capa de negocio: Toda aplicación tiene código para

implementar reglas de negocios, procesos relacionados a los datos
o cálculos y otras actividades relativas a los negocios.
Colectivamente este código es considerado para formar la capa de
negocios. Otra vez, uno de los principios del diseño lógico
cliente/servidor, la lógica de negocios debe mantenerse separada
de la capa de presentación y de los servicios de datos. Esto no
significa necesariamente que la lógica de negocios está en
cualquier parte, por el contrario, esta separación es en un sentido
lógico.
Hay muchas formas de separar la lógica de negocios. En términos
orientados a objetos, usted debería encapsular la lógica de
negocios en un conjunto de objetos o componentes que no
contienen presentación o código de servicios de datos. Teniendo
separada lógicamente su lógica de negocios de ambas, la capa de
presentación y servicios de datos, usted ganará en flexibilidad en
término de donde usted puede almacenar físicamente la lógica de
negocios. Por ejemplo, usted puede seleccionar almacenar la
lógica de negocios sobre cada estación de cliente, u optar por
ejecutar la lógica de negocios sobre un servidor de aplicaciones,
permitiendo a todos los clientes acceder a un recurso centralizado.

Los objetos de negocios son diseñados para reflejar o representar

sus negocios. Ellos se convierten en un modelo de sus entidades de
negocios e interrelaciones. Esto incluye tanto objetos físicos como
conceptos abstractos. Estos son algunos ejemplos de objetos del
mundo real: un empleado, un cliente, un producto, una orden de
compra.

Todos estos son objetos en el mundo físico, y la idea en su

totalidad detrás de usar objetos de negocios de software, es crear
una representación de los mismos objetos dentro de su aplicación.
Sus aplicaciones pueden hacer que estos objetos interactúen unos
con otros como ellos lo hacen en el mundo real. Por ejemplo, un
empleado puede crear una orden de compra a un cliente que
contiene una lista de productos. Siguiendo esta lógica usted puede
crear objetos de negocios de una orden conteniendo el código
necesario para administrarse a si mismo, así usted nunca
necesitará replicar código para crear ordenes, usted solo usará el
objeto. Similarmente, un objeto cliente contiene y administra sus
propios datos. Un buen diseño de un objeto cliente contiene todos
los datos y rutinas necesitadas para representarlo a través del
negocio completo, y puede ser usado a través de toda la aplicación
de ese negocio.

No toda la lógica de negocio es la misma. Alguna lógica de negocio

es un proceso intensivo de datos, requiriendo un eficiente y rápido
acceso a la base de datos. Otras no requieren un frecuente acceso
a los datos, pero es de uso frecuente por una interfase de usuario
robusta para la validación en la entrada de campos u otras
interacciones de usuarios. Si nosotros necesitamos una validación
al nivel de pantallas y quizás cálculos en tiempos real u otra lógica
de negocios, pudiéramos considerar este tipo de lógica de negocios
para ser parte de la IU, ya que en su mayor parte es usada por la
interfase de usuario.
Una alternativa de solución es dividir la capa de lógica de negocios
en dos:

• Objetos de negocios de la IU.

• Objetos de negocios de datos.

Un ejemplo del objeto Empleado de la capa objetos de negocios de

la IU proveerá propiedades y métodos para usar por el diseñador
de la interfase de usuario. Ejemplo de propiedades y métodos
pudieran ser: IDEmpleado, Nombre, Dirección, etc., y como
métodos crear una de compra, etc. El objeto Empleado de la capa
de objetos de negocios de datos será responsable de los
mecanismos de persistencias, interactuar con la base de datos. Los
objetos de esta capa son considerados sin estado, solo poseen
métodos.

Comprende las responsabilidades de lógica de negocio (o

dominio) del sistema.

 Resultado del análisis funcional:

 Conjunto de reglas de negocio que abstraen el mundo
real.

 La capa de negocio ha de ser independiente de la capa de

presentación y viceversa (en la medida de lo posible).
Funciones de la capa de Negocio:

 Recibir la información de la capa de presentación

 Interactuar con los servicios de datos para realizar la

lógica de negocio y de la aplicación.

 Enviar resultados a la capa de presentación

3 Capa de datos: es donde residen los datos. Está formada por uno
o más gestor de bases de datos que realiza todo el
almacenamiento de datos, reciben solicitudes de almacenamiento
o recuperación de información desde la capa de negocio. Capa que
sirve entre como puente entre la capa lógica de negocio y el
proveedor de datos. Este capa pretende encapsular las
especificidades del proveedor de datos tales como (SQL, Oracle,
Sybase, archivos XML, texto, hojas electrónicas), a la siguiente
capa. Para que si cambia el proveedor de datos solo necesitemos
cambiar en una sola capa el proveedor de datos. Hoy en día gracias
a la tecnología disponible y a la expansión del conocimiento a
través del Internet, tenemos a nuestra deposición la librería de
Microsoft Enterprise Library en su versión Dos, donde podemos
acceder sin necesidad de cambiar el código a proveedores OLEDB,
SQL, Oracle, XML, archivos Excel, etc. Por lo que si programamos
en .Net por capas la capa de acceso a datos debemos de utilizar
estas librerías para dejarle el trabajo a la misma y nosotros solo
preocuparnos con la conexión al proveedor de los datos y nada
mas.

Esta capa queda encargada de tomar la información de la base de

datos dada una petición de la capa de Reglas del Negocio, que a su
vez es generada por la capa de presentación.

Comprende las responsabilidades de lógica de persistencia de

las entidades que maneja el sistema en desarrollo.

 Inserción
 Eliminación
 Actualizaciones
 Búsquedas
 Etc

Funciones de la capa de Datos:

 Almacenar Datos

 Recibir datos

 Mantenimientos de los datos

  Integridad de los datos

Todas estas capas pueden residir en un único ordenador (no sería

lo normal), si bien lo más usual es que haya una multitud de
ordenadores donde reside la capa de presentación (son los clientes
de la arquitectura cliente/servidor). Las capas de negocio y de
datos pueden residir en el mismo ordenador, y si el crecimiento de
las necesidades lo aconseja se pueden separar en dos o mas
ordenador es. Así, si el tamaño o complejidad de la base de datos
aumenta, se puede separar en varios ordenadores los cuales
recibirán las peticiones del ordenador en que resida la capa de
negocio.

Si por el contrario fuese la complejidad en la capa de negocio lo

que obligase a la separación, esta capa de negocio podría residir
en uno o mas ordenadores que realizarían solicitudes a una única
base de datos. En sistemas muy complejos se llega a tener una
serie de ordenadores sobre los cuales corre la capa de datos, y
otra serie de ordenadores sobre los cuales corre la base de datos.

En una arquitectura de tres niveles, los términos "capas" y "niveles"

no significan lo mismo ni son similares.

El término "capa" hace referencia a la forma como una solución es

segmentada desde el punto de vista lógico:

Presentación/
Lógica de Negocio/
Datos.
En cambio, el término "nivel", corresponde a la forma en que las
capas lógicas se encuentran distribuidas de forma física. Por
ejemplo:

Una solución de tres capas (presentación, lógica, datos) que

residen en un solo ordenador (Presentación+lógica+datos). Se dice,
que la arquitectura de la solución es de tres capas y un nivel.

Una solución de tres capas (presentación, lógica, datos) que

residen en dos ordenadores (presentación+lógica, lógica+datos). Se
dice que la arquitectura de la solución es de tres capas y dos
niveles.

Una solución de tres capas (presentación, lógica, datos) que

residen en tres ordenadores (presentación, lógica, datos). La
arquitectura que la define es: solución de tres capas y tres
niveles.
• Ventajas

o Reutilización de capas;
o Facilita la estandarización
o Dependencias se limitan a intra-capa
o Contención de cambios a una o pocas capas
o darle seguridad y versatilidad al sistema
o porque con objetos es mas fácil hacer crecer la
aplicación
o es mas ordenado
o Clara distribución de las responsabilidades.
o Es más fácil trabajar en equipo con otros
desarrolladores y hasta armar equipos de
desarrolladores para cada capa.
o Podemos cambiar de repositorio de datos sin impacto
en el resto de la aplicación.
• Desventajas

o A veces no se logra la contención del cambio y se

requiere una cascada de cambios en varias capas;
o Pérdida de eficiencia;
o Trabajo innecesario por parte de capas más internas o
redundante entre varias capas;
o Dificultad de diseñar correctamente la granularidad de
las capas.
¿Cuál es la diferencia con la programación tradicional?

¿Por qué esto es mejor que programar todo de una sola vez y
qué diferencia hay entre una arquitectura y otra?

Las gráficas nos ayudarán a visualizar mejor estas diferencias.

MODELO TRADICIONAL

Todas las capas están ubicadas en un único elemento y al

actualizar un elemento se tendrán que afectar todos

En este el cambio en la capa de presentación no afectará reglas

del negocio y se pueden actualizar las funciones de reglas del
negocio sin tener que cambiar el acceso a datos.
MODELO THREE-TIER

Como podemos apreciar en las gráficas, resulta mucho más

práctico programar las capas por separado, sobretodo en
situaciones que tenemos un equipo de trabajo de diferentes
programadores o el proyecto es para una empresa con varias
sucursales con políticas independientes.

¿Cuándo es recomendable utilizar esta arquitectura?

 Cuando el proyecto es muy grande.

 Cuando son varios los programadores y existen

dificultades para coordinarlos, por ejemplo cuando el
software se está desarrollando con programadores
freelance que están muy lejos unos de los otros.

 Cuando el programa es para una empresa con varias

sucursales y cada sucursal puede tener algunos métodos
y políticas diferentes.
¿Cómo hacer mi proyecto con programación en 3 capas?

Si desea realizar un proyecto en tres capas, lo que debe hacer

básicamente es lo siguiente: Cree tres proyectos, dos de ellos
pueden ser de componentes o de Class library, eso lo decide el
programador. Una vez tenga estos tres proyectos, en uno de ellos
estarán solamente los formularios que le mostraremos al usuario.
En el otro proyecto tendremos funciones de verificación, por
ejemplo, verificar que la cuenta exista, que tenga dinero
suficiente, etcétera. En el tercero ponemos las funciones de
acceso a datos: la conexión, se define si se desean objetos
conectados o desconectados y se crean las funciones de asignación
de registros, modificación y eliminación. Por propósitos de
brevedad no mostraré un código completo, porque sería muy
extenso, pero estos parámetros lo podrán guiar perfectamente en
la creación de su aplicación. El código que irá en los formularios
solamente será para invocar las funciones de la capa de reglas del
negocio. Es decir, si creamos un botón de eliminar, el código que
irá en este será solamente la función borrar que debimos haber
creado en la capa de reglas del negocio. Por ejemplo:

Private Sub BtnEliminar_Click(ByVal sender As System.Object,

ByVal e As System.EventArgs) Handles BtnEliminar.Click
Dim Eliminador As New BussinessRules.DataBaseHandler()
Eliminador.DeleteRecord(129)
End Sub