Arquitectura 3 Capas, en entorno WEB
Le escribo porque estamos desarrollando una aplicación WEB con IIS, utilizando una mezcla de lenguajes que hacen que el código carezca por completo de claridad. Le hago un breve resumen de lo que hacemos: Tenemos páginas ASP, que se ejecutan y son interpretadas por el IIS, en estas páginas hay código de servidor en VBScript, código cliente javascript, y HTML. El código servidor hace llamadas a una DLL remota que obtiene los datos de la Base de datos.
Me gustaría saber si existe alguna otra forma de implementar esto, por ejemplo usando una capa cliente desarrollada íntegramente en HTML, siendo páginas ASP, que para rellenar sus listas y campos acceda a la capa remota que accede a la BD, pero que se mantengan esos datos en alguna capa intermedia, para si los necesito otra vez no tener que hacer acceso a la BD, sino que los recoja de esa capa intermedia.
De esta forma tendríamos una capa cliente que son páginas ASP/HTML, con una llamada a esa capa local, que haga una llamada a la capa remota y esta acceda a la BD, y vuelque el resultado en la capa local, de forma que la siguiente vez que necesite esos datoslos recojo de esa capa local.
No tengo ni idea de si existe alguna forma de implementar todo esto, o alguna manera de clarificar el código cliente haciendo distinción clara de lo que es cliente y lo que es servidor, evitar accesos repetitivos a la BD, etc...
El problema es que esta filosofía no he logrado implantarla ya que en cada página ASP, al hacer el submit paso a otra página asp, perdiendo cualquier referenca la capa local, de manera que empezaría de nuevo.
Me gustaría saber si existe alguna otra forma de implementar esto, por ejemplo usando una capa cliente desarrollada íntegramente en HTML, siendo páginas ASP, que para rellenar sus listas y campos acceda a la capa remota que accede a la BD, pero que se mantengan esos datos en alguna capa intermedia, para si los necesito otra vez no tener que hacer acceso a la BD, sino que los recoja de esa capa intermedia.
De esta forma tendríamos una capa cliente que son páginas ASP/HTML, con una llamada a esa capa local, que haga una llamada a la capa remota y esta acceda a la BD, y vuelque el resultado en la capa local, de forma que la siguiente vez que necesite esos datoslos recojo de esa capa local.
No tengo ni idea de si existe alguna forma de implementar todo esto, o alguna manera de clarificar el código cliente haciendo distinción clara de lo que es cliente y lo que es servidor, evitar accesos repetitivos a la BD, etc...
El problema es que esta filosofía no he logrado implantarla ya que en cada página ASP, al hacer el submit paso a otra página asp, perdiendo cualquier referenca la capa local, de manera que empezaría de nuevo.
Respuesta
1
En realidad lo que estas planteando es totalmente correcto e implementable. El problema que te frena es conceptual, me explico:
Tu estas pensando (es lo que deduzco) en un recordset que esta por hay en algún sitio y al que le pediré los datos cuando los necesite, pues bien, eso es un error de planteamiento.
El desarrollo de aplicaciones multicapa supone que tu tendrás proveedores de información y consumidores de esta.
En el caso del recordset: lo correcto seria que tuvieses una capa que fuese capaz de devolver un recordset y una capa que fuese capaz de pedir el recordset, modificarlo/tratarlo y pasarlo a otra capa de modo que seria un esquema como este:
Interface -> capa de negocios -> capa de datos
Donde el interface pide unos datos a la capa de negocios
La capa de negocios le pide esos datos a la capa de datos
La capa de datos los devuelve y pierde cualquier contacto con la capa anterior (por supuesto el interface NUNCA tendrá acceso directo a la capa de datos, solo a la de negocios)
La capa de negocios trata los datos y los devuelve al interface y se pierde el contacto.
Lo importante es que te des cuenta que, en aplicaciones de internet y/o multicapa, los recordsets son DESCONECTADOS y que no hay contacto permanente entre capas sino que hay una petición-respuesta y punto
Tu estas pensando (es lo que deduzco) en un recordset que esta por hay en algún sitio y al que le pediré los datos cuando los necesite, pues bien, eso es un error de planteamiento.
El desarrollo de aplicaciones multicapa supone que tu tendrás proveedores de información y consumidores de esta.
En el caso del recordset: lo correcto seria que tuvieses una capa que fuese capaz de devolver un recordset y una capa que fuese capaz de pedir el recordset, modificarlo/tratarlo y pasarlo a otra capa de modo que seria un esquema como este:
Interface -> capa de negocios -> capa de datos
Donde el interface pide unos datos a la capa de negocios
La capa de negocios le pide esos datos a la capa de datos
La capa de datos los devuelve y pierde cualquier contacto con la capa anterior (por supuesto el interface NUNCA tendrá acceso directo a la capa de datos, solo a la de negocios)
La capa de negocios trata los datos y los devuelve al interface y se pierde el contacto.
Lo importante es que te des cuenta que, en aplicaciones de internet y/o multicapa, los recordsets son DESCONECTADOS y que no hay contacto permanente entre capas sino que hay una petición-respuesta y punto
Perdona, pero a lo mejor el planteamiento ha hecho que no me explicara correctamente. La realidad es que ya hemos contemplado dos posibilidades de implementación de la teoría de tres capas.
Capa de presentación-->ASP
Capa Negocio -->clases VisualBasicScript, interpretada por IIS
Capa Remota de Acceso a datos-->dll, ActiveX, VissualBasic
Opción 2
Capa de presentación-->ASP
Capa Negocio -->dll, ActiveX, Visual Basic
Capa Remota de Acceso a datos-->dll, ActiveX, Visual basic
El problemas es que no estamos seguros de que opción tomar y si hay alguna otra solución. Lo que queremos una clarificación del código cliente, y la mayor rentabilidad del código.
Capa de presentación-->ASP
Capa Negocio -->clases VisualBasicScript, interpretada por IIS
Capa Remota de Acceso a datos-->dll, ActiveX, VissualBasic
Opción 2
Capa de presentación-->ASP
Capa Negocio -->dll, ActiveX, Visual Basic
Capa Remota de Acceso a datos-->dll, ActiveX, Visual basic
El problemas es que no estamos seguros de que opción tomar y si hay alguna otra solución. Lo que queremos una clarificación del código cliente, y la mayor rentabilidad del código.
La primera opción no es del todo correcta.
En desarrollos multicapa no se debe hacer una función que calcule la letra del NIF, por ejemplo y la imprima en pantalla puesto que eso seria mezclar capas. En realidad deberías hacer una dll que tuviese un parámetro de entrada que seria el DNI y un parámetro de salida que seria la letra del NIF.
En este tipo de desarrollos el lenguaje no es importante hasta el punto que en el nuevo desarrollo de Microsoft para estos entornos no hay distinción entre lenguajes a la hora de correr, depurar, etc el programa.
Tienes que tener en cuenta que para llevar a cabo con éxito estos planteamientos se debe hacer un cambio de mentalidad a la hora de programar
No se si te estoy entendiendo bien, pero no estas en absoluto lejos de la solución correcta, simplemente tienes que cambiar el planteamiento a la hora de llevar a cabo la implementación de lo que estas pensando.
En desarrollos multicapa no se debe hacer una función que calcule la letra del NIF, por ejemplo y la imprima en pantalla puesto que eso seria mezclar capas. En realidad deberías hacer una dll que tuviese un parámetro de entrada que seria el DNI y un parámetro de salida que seria la letra del NIF.
En este tipo de desarrollos el lenguaje no es importante hasta el punto que en el nuevo desarrollo de Microsoft para estos entornos no hay distinción entre lenguajes a la hora de correr, depurar, etc el programa.
Tienes que tener en cuenta que para llevar a cabo con éxito estos planteamientos se debe hacer un cambio de mentalidad a la hora de programar
No se si te estoy entendiendo bien, pero no estas en absoluto lejos de la solución correcta, simplemente tienes que cambiar el planteamiento a la hora de llevar a cabo la implementación de lo que estas pensando.