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

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 ejemplo que estudio, esta capa la llaman "Business Logic". La componen
clases especializadas que facilitan el trabajar con las tablas físicas de la
BD. Ejemplos de su uso:

Clientes = new Clientes()
Clientes.CLAVE="123";
Clientes.Eliminar();

Clientes.CLAVE="456";
Clientes.NOMBRE="Empresa 456, S.A.";
Clientes.Agregar();

La capa de presentación consume este grupo de clases, cuyas propiedades son
los campos de la tabla y tiene métodos para agregar, eliminar, etc.

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?

Bueno, en el modelo que estoy estudiando, la capa de arriba es la de
presentación, que puede ser una aplicación Windows.Forms o ASP.NET. La
intermedia es el conjunto de las clases especializadas para cada tabla, que
describí arriba. Y la baja es un conjunto de varios procedimientos
almacenados por cada tabla, por ejemplo sp_CLIENTES_INS para agregar
registros a la tabla. La capa intermedia manda llamar estos procedimientos a
traves de objetos Comando de ADO.NET

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.



Seguro que esto es lo mas razonable?

Y come te aseguras la integridad de los datos?

Por cierto Sql Server soporta "assertions" ?

Tosdos tenemos en nuestra cabeza como debiera ser un buen SGBD, pero claro
es teoria noy hay nadie con los suficientes para desarrollarlo
practicamente, quizas C omega empiece con unos pinitos pero al final creo
que tampo llegara a ningun sitio.


Saludos.

"Alfredo Novoa" escribió en el mensaje
news:

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

On Tue, 31 May 2005 19:00:08 -0500, "Benton"
wrote:

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

En el ejemplo que estudio, esta capa la llaman "Business Logic". La componen
clases especializadas que facilitan el trabajar con las tablas físicas de la
BD. Ejemplos de su uso:

Es decir que es parte de la aplicación.

Esto está completamente mal. La lógica de negocio debe de ser
asegurada por el SGBD, que sirve justo para eso.

La aplicación debe de encargarse únicamente de la presentación de los
datos y la comunicación con los usuarios.

Clientes = new Clientes()
Clientes.CLAVE="123";
Clientes.Eliminar();

Clientes.CLAVE="456";
Clientes.NOMBRE="Empresa 456, S.A.";
Clientes.Agregar();

Aquí estás construyendo un interfaz procedimental para encapsular a
SQL, y esto es una de las peores cosas que puedes hacer.

La capa de presentación consume este grupo de clases, cuyas propiedades son
los campos de la tabla y tiene métodos para agregar, eliminar, etc.

La capa de presentación de un sistema de información son las
aplicaciones, la capa de negocio es el SGBD y la capa "baja" es el
subsistema de archivos del sistema operativo.

Crear una aplicación es mucho más sencillo que todo eso. Lo que tienes
que hacer es implementar toda la lógica de negocio usando un SGBD y
mapear los formularios a las tablas lógicas de la base de datos de la
forma más directa posible.

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

Bueno, en el modelo que estoy estudiando, la capa de arriba es la de
presentación, que puede ser una aplicación Windows.Forms o ASP.NET. La
intermedia es el conjunto de las clases especializadas para cada tabla, que
describí arriba. Y la baja es un conjunto de varios procedimientos
almacenados por cada tabla, por ejemplo sp_CLIENTES_INS para agregar
registros a la tabla. La capa intermedia manda llamar estos procedimientos a
traves de objetos Comando de ADO.NET

Pues parece que ese modelo está muy confundido por que mezcla capas de
sistema con capas de aplicación y además la arquitectura es
disparatada. Los que han escrito eso no tienen ni idea.


Saludos

On Wed, 1 Jun 2005 10:03:29 +0200, "José Antonio"
wrote:

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.



Seguro que esto es lo mas razonable?

Segurísimo.

Y come te aseguras la integridad de los datos?

Con los mecanismos que proporciona el SGBD para hacer eso: dominios,
tablas, claves primarias y secundarias, aserciones, procedimientos
almacenados y tipos definidos por el usuario.

Por cierto Sql Server soporta "assertions" ?

No, lo cual es una seria limitación. SQL Server solo soporta el nivel
de compatibilidad más bajo con el estandar SQL.

Tosdos tenemos en nuestra cabeza como debiera ser un buen SGBD

Lo dudo mucho.

, pero claro
es teoria noy hay nadie con los suficientes para desarrollarlo
practicamente, quizas C omega empiece con unos pinitos pero al final creo
que tampo llegara a ningun sitio.

C omega no tiene nada que ver con un SGBD, pero aunque SQL Server no
soporte "assertions" podemos implementar igualmente cualquier lógica
de negocio con él. Lo único que va a pasar es que nos va a costar más
trabajo hacerlo con procedimientos almacenados.

Aunque también podríamos usar otros SGBD que hay en el mercado con más
prestaciones que SQL Server.


Saludos