Arquitectura de tres capas con Access

Ante la realidad de que muchos estudiantes carecen de las destrezas necesarias para utilizar con versatilidad lenguajes de programación en el diseño y creación de aplicaciones distribuidas, he preferido desarrollar las tres capas: la capa de Presentación o Interfaz de usuario (IU), la capa Lógica de Negocio y la capa de Acceso o Servicios de Datos con una aplicación que pueda ser familiar al estudiante de cualquier concentración.

Con Acces, podemos hacer, entre otras cosas, 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.

Que distribuidas entre las tres capas, se vería así:

1. Interfase de usuario (Capa de Presentación)

o Interactuar con otros usuarios.

o Interactuar con aplicaciones externas o servicios.

2. 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.

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

o Manipulación de datos.

o Ejecución de las reglas de datos relacional.

Especificaciones Técnicas

El mismo carece de complejidad, la única intención ha sido la de mostrar como se desarrolla una aplicación cliente/servidor empleando un diseño distribuido. Es suficiente con una sola estación de trabajo (Aplicación basada en Host) que tenga instalado el sistema operativo Microsoft Windows 2000 para su ejecución, aunque pudiera distribuirse por varias computadoras en una red.

Arquitectura de las tres capas

Básicamente la Arquitectura se centra en un arquitectura de 3 partes, las cuales pueden distribuirse en una, dos y tres capas.

1. La capa de presentación que en este caso esta formada por los Componentes de IU, y los componentes de proceso de IU. Los componentes de IU pueden ser vistos como la parte con la cual interactuar el usuario. Las ventanas o páginas web, por decirlo de alguna manera. Los componentes de proceso de IU podríamos asociarlos a clases de tipo controladora en UML. Es decir estos encapsulan lógica de navegación y control de eventos de la interfase.

2. La capa de negocios encapsula lógica de negocios. Los servicios de esta capa son encapsulados en tres tipos de componentes, dos de los cuales se tocan en este ejercicio. Las entidades empresariales, que representan objetos que van a ser manejados o consumidos por toda la aplicación, estos podrían ser un modelo de objetos, xml, datasets con tipo, estructuras de datos, que permitan representar objetos que han sido identificados durante el modelamiento. Los otros tipos de objetos son los componentes empresariales que contienen lógica de negocio, y en algunos casos al usar COM+ son los objetos raíz que inician las transacciones.

3. La capa de acceso a datos que contiene clases que interactúan con la base de datos. Estas clases surgen como una necesidad de mantener la cohesión o clases altamente especializadas que ayuden a reducir la dependencia entre las clases y capas.

Las tres partes de las Aplicaciones en una, dos o tres capas

Se puede decir que todas las aplicaciones tienen la misma arquitectura básica y se pueden subdividir en tres partes:

• Interfaz del Usuario: La presentación al usuario, con las entradas de datos y las pantallas de consulta.
• Reglas de negocio: Sería el procesamiento de la información.
• Accesos a Datos: El control del almacén de datos.

Aplicaciones mono-capa

Entendemos por aplicaciones mono-capa, aquellas que tanto la propia aplicación como los datos que maneja se encuentran en la misma máquina y son administradas por la misma herramienta: podríamos decir que son una sola entidad

Figura 1. Arquitectura Típica de una aplicación de una sola capa.

Aplicaciones con Arquitectura en dos capas (Two-Tier)

Estas aplicaciones son más conocidas como aplicaciones Cliente/Servidor y lo más característico es que dividen una aplicación entre un cliente y un servidor estableciendo un middleware que controla las comunicaciones entre ambos. Un programa Visual FoxPro que interroga a una Base de Datos SQLServer es un ejemplo de aplicación en dos capas.

En la raíz de las aplicaciones cliente/servidor está la separación de la aplicación en componentes encapsulados u objetos. La ventaja de romper una aplicación en trozos es que cualquier cambio de uno de esos componentes no tiene un impacto directo sobre los otros o en el resto de la aplicación.

En las arquitecturas two-tier, la aplicación se divide en dos entidades separadas.

La arquitectura two-tier dividida en dos entidades con el interfaz por un lado y las reglas de negocio junto con el Acceso a Bases de Datos por otro se muestran en la Figura 2.

Figura 2. Arquitectura Two-tier con el interfaz y las reglas de negocio encapsuladas juntas.

O se podría poner en el mismo lado el interfaz junto con las reglas de negocio y tendríamos lo que se muestra en la Figura 3.

Figura 3. Arquitectura Two-tier con el acceso a la Base de Datos y las reglas de negocio encapsuladas.

¿Qué método es mejor? Como regla general poner reglas de negocio ligados a un interfaz es una mala idea ya que fuerza a que cada cambio en la aplicación nos lleve a ir usuario por usuario cambiándole la aplicación.

Encapsular las reglas de negocio junto con los datos tiene la ventaja de que se pueden cambiar sin tener que tocar los interfaces de los clientes que seguramente estarán muy distribuidos. El inconveniente es que normalmente los Servidores de Datos no son muy moldeables y es bastante complicado implementar reglas de negocio en los servidores.

Muchas aplicaciones two-tier combinan de forma conjunta ambos sistemas. Es con frecuencia impracticable o indeseable, encapsular completamente los procesos con los datos.

En estas aplicaciones el Servidor de Datos procesa las Consultas y realiza todas las actividades relacionadas con la Base de Datos. Cada Cliente inicia y deja abierta una conexión al servidor para poder enviar las peticiones y poder procesar las respuestas.

Normalmente la lógica se establece en el cliente usando un lenguale 3GL o 4GL o en el servidor mediante Triggers y Procedimientos Almacenados. Dependiendo de donde establezcas la lógica tendrás un Fat Client o un Fat Server.

Este modelo suele ser costoso de mantener, difícil de escalar y pesado de depurar.

Aspectos a tener en cuenta a la hora de pasar de una aplicación de una sola capa a otra en dos Capas

§ Usa Vistas Locales en vez de acceder a tablas directamente

§ Encapsula las reglas de negocio fuera de contenedores visuales. Las Reglas de Negocio deberían ir en clases no visuales tipo Custom.

Arquitectura Three-Tier

Como se podría esperar cada uno de los componentes de la aplicación en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera más flexible. Algo que no creo que sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.

En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es bastante importante pues eso quiere decir que:

1. El cliente no tiene que tener drivers ODBCni la problemática consiguiente de instalación de los drivers por tanto se reduce el costo de mantener las aplicaciones cliente

2. El Cliente y el Gestor de Reglas de negocio tienen que hablar el mismo lenguaje (en nuestro caso COM)

3. El Gestor de Reglas de Negocio y el Servidor de Datos tienen que hablar el mismo lenguaje (en nuestro caso ODBC)

Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open

Empezaremos por lo básico, esto es, por la base de datos.

Home | Diseño Aplicaciones |