Sobre las aplicaciones multicapa

On Tue, 31 May 2005 15:36:30 -0500, "Benton"
wrote:

Hola,

Estoy analizando un ejemplo de aplicación en tres capas, para usarlo como
modelo en un proyecto que tengo enfrente.

¿Aplicación en tres capas o sistema en tres capas?

La capa de más bajo nivel es la que realiza las operaciones en la base de
datos, esta capa la constituyen básicamente un montón de procedimientos
almacenados

Si una capa está formada por procedimientos almacenados entonces está
claro que estamos hablando de un sistema de tres capas. Los
procedimientos almacenados no son parte de la aplicación.

que se encargan de insertar, modificar, elinimar y extraer
registros de la tablas.

Y también se deben de encargar de asegurar la integridad de los datos,
es decir de que después de una inserción, modificación o borrado la
base de datos no pueda quedar en un estado inconsistente.

Pero el problema es que parece que quieres construir una interfaz
procedimental (bajo nivel) sobre la interfaz declarativa de SQL (alto
nivel), y eso es un error.

Las aplicaciones deben de comunicar con el SGBD a través de SQL, que
para eso está.

Además del tema de la comunicación, siempre se debe de favorecer el
código declarativo sobre el código procedimental, es decir que todo lo
que pueda implementarse con vistas y restricciones de integridad
declarativas (keys y assertions) debe de hacerse así y no mediante
procedimientos almacenados.

Lo malo es que si usas un SGBD que no soporta "assertions" vas a tener
que implementar muchas reglas de negocio usando procedimientos
almacenados.

La capa intermedia (en C#) manda llamar a estos procedimientos con los
parámetros adecuados.

¿Para que sirve esta capa?

¿La capa intermedia es parte de la aplicación cliente o es otra
aplicación?

En el primer caso estaríamos hablando de un sistema de dos capas.

Ahora bien, mi idea es eliminar la capa "baja" y hacer que la capa
intermedia, en vez de llamar procedimientos almacenados, genere
dinámicamente el SQL que necesita en cada operación y lo ejecute. De esta
manera me evito crear y mantener cuatro o cinco procedimientos por cada
tabla.

Eso es lo más razonable. Evitas crear un montón de procedimientos
almacenados que no sirven para nada.

Pero la duda que me queda es: ¿En que consiste la capa que falta?

Por una parte tienes el SGBD que asegura toda la lógica de negocio y
por otra la aplicación que implementa la lógica de presentación y se
comunica con el SGBD usando SQL. Esto es un típico sistema de dos
capas que funciona estupendamente siempre que el SGBD aguante la carga
de trabajo.

En caso de necesitar más potencia podrías pasar a un sistema de tres
capas descomponiendo la capa del SGBD dos o más capas físicas, y esto
debería de poder hacerse sin tener que tocar la aplicación.


Saludos