Por Alberto Rodriguez
© Copyrights 1997 by FoxPress, All rights reserved
FoxPress, Septiembre 1997
Hay muchos programadores
para los que programar consiste en estar delante de un teclado escribiendo
código, cualquier otra actividad es una pérdida de tiempo.
Sin embargo, la
experiencia ya viene demostrando como antes de empezar a escribir código es
necesario previamente parar a pensar:
El análisis de la
aplicación no sólo debe satisfacer las necesidades presentes sino que tiene que
estar preparada para los posibles cambios que el cliente pueda pedir sin tener
que reescribir totalmente la aplicación: la experiencia de aplicaciones
similares y el conocimiento del mercado debe hacernos dejar las suficientes
puertas abiertas como para poder implementar mejoras a la aplicación; esto es
lo que se suele llamar flexibilidad.
Se puede decir que todas
las aplicaciones tienen la misma arquitectura básica y se pueden subdividir en
tres partes:
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.
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.
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.
Figura 4. Arquitectura Three-Tier.
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:
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
La elección entre
arquitecturas two- y three-tier es independiente del Hardware que se tenga. Los
desarrolladores han estado implementando aplicaciones Cliente/Servidor desde
los primeros tiempos de la programación excediendo muchas veces las
posibilidades del Hardware sobre el que corrían. Se rompe la aplicación en
muchos trozos que dialogan entre sí.
Afortunadamente, en la
actualidad el hardware, las redes y los sistemas operativos permiten a los
desarrolladores implementar aplicaciones de una forma que antes era
abosolutamente imposible. Una aplicación desarrolladda usando un modelo en tres
capas se puede desarrollar en un PC, incluso en un NetPc o en entornos tan
diversos como Mac, Microsoft Windows NT™ o servidores Unix dando servicios a
aplicaciones de datos en redes Microsoft Windows® o Mac. Una apliación
Three-tier no sirve para nada si no es escalable.
Implementar aplicaciones
cliente/servidor conlleva muchos problemas que podríamos subdividir en tres
categorías:
Es necesario tomar estas
consideraciones debido a que la aplicación se rompe en múltiples trozos que
corren en diferentes PC y con frecuencia envoviendo diversos Sistemas
Operativos.
El problema principal de
las aplicaciones Cliente/Servidor es el control de las comunicacines y las
notificaciones de los eventos asíncronos. Este problema también existe en las
arquitecturas three-tier lo mismo que en las two-tier donde los datos y las
reglas de negocio se guardan de forma conjunta.
Si la aplicación va a
funcinar en entornos que unicamente son Windows , se podría usar OLE o DDE para
disparar los eventos y controlar las tareas. Es fácil de usar, rápido de
implementar y funciona en la red.
Si la aplicación va a
funcionar en diversos entornos se debería considerar seriamente el uso de
herramientas que soporten otros estándares coo el standard Distributed Computing
Environment (DCE) que define la forma cómo se deben tratar los servicios, la
seguridad y el acceso a redes y ya que es implementado por casi todos los
vendedores permitiría trabajar con diversos entornos y sistemas.
Para hacer aplicaciones
cliente/servidor que funcionen bien se debe tener en cuenta algunos aspectos
como:
Arquitecturas que
almacenan grandes bases de datos en los servidores de red y usan una lógica que
está en cada PC cliente violan las reglas anteriores y su rendimiento es
bastante malo.
La optimización de las
velocidades de acceso es el gran problema de estas aplicaciones. En una
implementación cliente/servidor, algunos datos se deben guardar en el cliente
por razones de optimización. Esto ocurriría con algunas tablas estáticas que
cambian poco
Admitida que estas
Arquitecturas son más complicadas y es una dificultad añadida a la hora de
implementarlas. Sin embargo, la complejidad añadida y los esfuerzos aplicados
conllevan unos beneficios reales.
Aplicación de mantenimiento
de una tabla en VFP 5.0.
Características:
Aplicación de
mantenimiento de una tabla en VFP 5.0.
Características:
Este es el formato ideal
para las aplicaciones mono-capa que en un futuro corto se tendrán que pasar a
Cliente/Servidor. El hecho de tener las vistas sin parametrizar conllevará
costos añadidos en la transformación y en la optimización dela red.
Aplicación de
mantenimiento en VB de una tabla .DBF
Características:
Alberto
Rodriguez es socio de Fox Software y se puede entrar en contacto con él en alb@datapress.com
Reproducido
de:
http://www.fpress.com/revista/Num9711/Nov97.htm