Ayuda modelo de tres capas...

30/06/2005 - 15:56 por Demian | Informe spam
Hola, tengo una duda en cuanto al modelo de tres capas..

En general no se donde deben escribirse los comando sql de mi aplicacion, no
se si es parte de la capa de datos o bien es parte de la capa logica...

Entiendo que puedo programar procedimientos almacenados para recuperar la
información y despues mediante los proveedores de datos de .net ejecutarlos,
con lo cual obviamente mis sentecnias sql estarian en el lado de la capa de
datos y obtendría una aplicacion mas migrable, sin embargo, todas mis
aplicaciones estarían en un servidor y esto podria afectar el rendimiento del
mismo.

Otra opcion es tener una funcion de datos para cada accion que desee
realizar en el servidor, por ejemplo un metodo InsertarPedido, otro
InsertarFactura, y otro mas llamado InsertarAmortizaciones. Esto estaria
bien, sin embargo alarga el tiempo de desarrollo de aplicaciones.

La opcion que estopy tomando es tener funciones de datos generales, por
ejemplo
InsertarRegistro o bien InsertarRegistros, a las cuales les paso comandos
sql o bien una lista de parametros que la funcion pueda reconocer y con ello
construior un comando que ejecutaria posteriormente. El asunto con esto que
mi applicacion no es tan migrable y apartentemente mezcla un poco la logica
de negocio con la capa de datos, sin embargo me gustaría saber si lo que
estoy haciendo es conveniente y de no serlo cuales son las razones por las
cuales no debo programar de esta forma.
 

Leer las respuestas

#1 Alfredo Novoa
30/06/2005 - 18:08 | Informe spam
On Thu, 30 Jun 2005 06:56:21 -0700, Demian
wrote:

Hola, tengo una duda en cuanto al modelo de tres capas..

En general no se donde deben escribirse los comando sql de mi aplicacion, no
se si es parte de la capa de datos o bien es parte de la capa logica...



Las aplicaciones cliente son la capa de presentación y comunicación
con los usuarios de un Sistema de Información.

La capa de lógica de negocio es el SGBD y la capa de base de datos son
los archivos en donde se guarda la base de datos, a los que no deben
de tener acceso las aplicaciones.

Por lo tanto los comandos SQL de una aplicación son parte de la capa
de presentación y comunicación. Son los que definen los datos que
vamos a presentar y los que van a ayudar a codificar las peticiones de
los usuarios para que las pueda entender el SGBD.

Entiendo que puedo programar procedimientos almacenados para recuperar la
información y despues mediante los proveedores de datos de .net ejecutarlos,
con lo cual obviamente mis sentecnias sql estarian en el lado de la capa de
datos y obtendría una aplicacion mas migrable



No ganarías nada con eso y perderías mucho tiempo.

Estén en donde estén las sentencias SQL se van a ejecutar en el
servidor, así que te da igual.

Crear un interfaz procedimental para encapsular un diseño de base de
datos relacional no aporta ningún valor, cuesta tiempo y trabajo
hacerlo y añade dificultades al mantenimiento, por que además de tener
que mantener el diseño de la base de datos también vas a tener que
mantener el interfaz hecho con procedimientos almacenados y
mantenerlos sincronizados.

, sin embargo, todas mis
aplicaciones estarían en un servidor y esto podria afectar el rendimiento del
mismo.



Eso no suele ser un problema. Siempre puedes poner un servidor más
potente o varios servidores.

Otra opcion es tener una funcion de datos para cada accion que desee
realizar en el servidor, por ejemplo un metodo InsertarPedido, otro
InsertarFactura, y otro mas llamado InsertarAmortizaciones. Esto estaria
bien, sin embargo alarga el tiempo de desarrollo de aplicaciones.



Esto en el fondo es casi igual a lo anterior y por eso alarga el
tiempo de desarrollo y mantenimiento.

Lo mejor es encapsular toda la lógica de negocio que se pueda en
vistas, así las sentencias SQL serán muy sencillas y fáciles de
entender.

Después solo tendrías que "mapear" las vistas de la base de datos a
los controles visuales de tu aplicación intentando usar la menor
cantidad de código posible.

Esto es muy sencillo de hacer con Delphi .Net, y no tanto con Visual
Studio 2003.

La opcion que estopy tomando es tener funciones de datos generales, por
ejemplo
InsertarRegistro o bien InsertarRegistros, a las cuales les paso comandos
sql o bien una lista de parametros que la funcion pueda reconocer y con ello
construior un comando que ejecutaria posteriormente.



Yo lo que hago es usar un componente para mapear tablas de la base de
datos a los controles de un formulario y listo. El resto es
automático. Cuando inserto un registro en un grid, por ejemplo, el
componente se encarga de generar la sentencia SQL correspondiente y de
enviarla al SGBD.


Saludos

Preguntas similares