Breve introducción a "n" Capas

Cuando se trabaja en "n capas" se subdividen los módulos de la aplicación en partes. En el caso de 3 capas éstas serían: interfaz (pantallas, menúes, todo lo visual), negocio (reglas, validaciones) y datos (locales o remotos). Una ventaja de este tipo de diseño es que 3 (o "n") grupos de trabajo pueden trabajar a la vez en el mismo múdulo, pudiendo terminarse en casi 1/3 (o 1/n) del tiempo, ya que cada equipo (o persona) se dedicaría a hacer una capa completa. Lo único que haría falta (o ayudaría) para que esto pueda cumplirse es tener un buen diseño donde esta separación ya esté hecha y definir de antemano cuáles serán los nexos entre dichas capas.

Por ejemplo, en mi caso, una de las cosas que primero defino (luego del diseño que yo haga o me den) es el nombre de los objetos y las propiedades y el detalle de qué es cada cosa y cuáles se deben almacenar, calcular ,etc. Sólo con esto el equipo que se encarga de la capa de datos puede definir la estructura de las tablas (en VFP, Oracle, etc) y las clases de acceso a las mismas, mientras el equipo que se encarga de la interfaz puede comenzar a diseñar la(s) pantalla(s), el equipo que se encarga de la impresión puede comenzar a diseñar los informes y finalmente el equipo que se encargue del negocio puede comenzar a programar los métodos de validación que hagan cumplir las reglas.

Separando las capas: Ejemplos de cada una

INTERFAZ: Es la más conocida porque siempre estuvimos trabajando en esta capa la casi totalidad de las aplicaciones, salvo que en este caso la interfaz sólo debe ser lo mínimo y necesario para que se puedan mostrar los datos u opciones disponibles. La interfaz se puede vincular con el negocio y los datos de forma transparente mediante métodos preestablecidos, tales como GuardarDatos(), RecuperarDatos() o ValidarDatos(). Tomando como ejemplo la típica barra de navegación que viene con VFP en sus ejemplos, la cuál deja avanzar o retroceder por los registros, podría separarse ésta en la parte visual (los botones de navegación) y su funcionalidad ponerla en una clase no-visual (custom, session u otra). De esta forma el botón "Siguiente" ejecutaría el método RegistroSiguiente() o el botón anterior el método RegistroAnterior() de la clase que implementa esa funcionalidad. De la misma forma, los menúes no hacen nada, excepto llamar a métodos de negocio que harán el trabajo necesario.

DATOS: Es otra de las que más conocemos, ya que siempre estuvimos pegando las tablas en el entorno de datos de los formularios: ya no. Si la capa de datos debe estar separada, entonces debería tener una o varias clases que abran las tablas, actualicen o consulten los datos y cierren las tablas. Una idea sobre esto: Si bién podrían usarse clases tipo custom o session para esto, recientemente implementé una idea que consiste en usar la clase dataenvironment como "entorno de transacciones" (en vez de entorno de datos), o sea que en dicha clase creo un cursor por cada tabla que participará de la transacción (por ejemplo cabecera y detalle de albaranes, facturas, remitos, etc.) De esta forma se pueden actualizar varias tablas a la vez usando buffering de tablas y transacciones. La diferencia del uso que yo le dí es que en dicho entorno no abro todas las tablas que necesito, sino sólo las que corresponden al mismo grupo de datos porque están involucradas en la actualización. Dos de las formas de manipular los datos son: directamente (o con buffering) o indirectamente mediante el uso de objetos y propiedades que luego se vuelcan a las tablas. Esta última aproximación se podría comparar en cierta forma a la técnica que usábamos antes de que exista el buffering, donde se almacenaba todo en variables (que ahora son propiedades) lo que permite mantener las tablas cerradas mientras dura la edición de los datos. Las clases de datos pueden devolver de una consulta pedida los conjuntos de resultados en forma de un cursor de datos, un array, XML o cualquier otra forma.

NEGOCIO: Esto es el corazón de la aplicación. Si bién se le dice "negocio", en realidad se puede tratar de varios negocios, cada uno destinado a una función distinta. Por ejemplo, puede haber un negocio de datos (integridad referencial), un negocio de la interfaz, que se encarga de abrir y cerrar los formularios, de habilitar e inhabilitar las opciones del menú y que posee todos los métodos que serán llamados desde las distintas partes de la interfaz, y un negocio que se encarge del trabajo fino de validación del ingreso del usuario, el cuál puede determinar si se puede o no modificar un valor, calcula totales y subtotales, devolver los códigos de error que luego la interfaz interpreta y muestra al usuario en forma de texto, etc. Estos objetos de negocio suelen ser clases no visuales (custom, session, etc) y es posible accederlos remotamente o localmente.

Bueno, esto es más o menos una síntesis de lo que significa el trabajo en capas. Es algo interesante, algo laborioso al principio, pero en general te ahorra tiempo a largo plazo si fué bién diseñado, ya que con un buen diseño las capas se deberían poder cambiar de forma independiente sin afectar a las demás. Por ejemplo, podrías tener varias interfaces para distintos tipos de usuario que ataquen al mismo negocio, o usar tablas VFP y luego hacer upsizing a tablas de Oracle, SQL Server, etc.

Fernando D. Bozzo
Madrid / España