Ayuda modelo de tres capas...

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

Antes que nada agdezco el tiempo de contestar mi pregunta, sin embargo me
surge una pequeña en relación a como puede trabajar tu componente...

Voy a atratar de plantear de manera muy generalizada la forma en que
interpreto que pueden tabajar tus clases para el ejemplo que me das del
datagrid..

1. Tendrias un componenete(obvio simplificado) mas o menos asi..
Public Class ComponenteSql
Dim Tabla as string
Dim InsertComand as string
Public Function GenerarComandoInsert() as string
' mas algunas otras propiedades que pueda tener el componente
end class
2. Al insertar un nuevo registro pasaría lo siguiente:
'supongamos que esta instanciada la clase del componente, que estamos
'insertando un nuevo pedido y que existe una capa logica que hace las
validaciones
'de la nueva fila insertada

Private sub On_RowChanging
' La funcion GenerarComandoInsert probablemente se basaria en el
' esquema de la tabla para interpretar lo que se desea hacer

Componente.GenerarComandoInsert

'En esta funcion se validaria que el datarow que se esta insertando
tenga los
'valores adecuados (pertenece a la capa logica del negocio)

if CapaLogicaDeNegocio.Pedido.ValidarPedido(NuevoDataRowPedido = True
'La siguiente función llamaría a una clase general que se
encarga de
'ejecutar comando generales de Ado.net

ClaseComandos.EjecutarComando(Componente.ComandoInsert)

end if
end sub

Abusando de tu confianza te pregunto si de esta manera es como funcionaria
mas o menos?, o cuales modificaciones le harias al codigo que planteo...










"Alfredo Novoa" wrote:

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

Hola Demian,

Yo te recomiendo desarrollar una serie de componentes que forman la lógica
de negocio, que expondrían toda la funcionalidad que necesites (crear
Pedido, obtener Pedido, etc)
Dentro de estos componentes utilizaría procedimientos almacenados, es lo
recomendado, pero podrías utilizar tambien sentencias SQL, cuidado con la
injección de codigo.
Y consumiría estos componentes desde la interfaz de usuario, que podría ser
Web, Windows, VSTO, etc.
¿Donde situar esos componentes intermedios? por ahora tienes que tomar la
decisión en función de las necesidades que tengas para el proyecto (COM+,
WebService, Remoting, etc), en un futuro tendras Indigo que permitirá
cambiar de uno a otro mediante configuración.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Demian" escribió en el mensaje
news:

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.

On Thu, 30 Jun 2005 21:28:10 +0200, "Miguel Angel Campos"
<SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote:

Yo te recomiendo desarrollar una serie de componentes que forman la lógica
de negocio, que expondrían toda la funcionalidad que necesites (crear
Pedido, obtener Pedido, etc)
...
¿Donde situar esos componentes intermedios? por ahora tienes que tomar la
decisión en función de las necesidades que tengas para el proyecto (COM+,
WebService, Remoting, etc), en un futuro tendras Indigo que permitirá
cambiar de uno a otro mediante configuración.

Esto está muy bien si tus objetivos son maximizar el tiempo de
desarrollo y los costes de mantentimiento (y no te importa tener una
aplicación muy lenta), algo que desean muchas consultoras.

Si tus objetivos son los contrarios es mucho mejor hacer algo como
esto:

http://www.intsight.com/whidbeydb/whidbey.html


Saludos

On Thu, 30 Jun 2005 11:00:03 -0700, Demian
wrote:

Antes que nada agdezco el tiempo de contestar mi pregunta, sin embargo me
surge una pequeña en relación a como puede trabajar tu componente...

Voy a atratar de plantear de manera muy generalizada la forma en que
interpreto que pueden tabajar tus clases para el ejemplo que me das del
datagrid..

1. Tendrias un componenete(obvio simplificado) mas o menos asi..
Public Class ComponenteSql
Dim Tabla as string
Dim InsertComand as string
Public Function GenerarComandoInsert() as string
' mas algunas otras propiedades que pueda tener el componente
end class
2. Al insertar un nuevo registro pasaría lo siguiente:
'supongamos que esta instanciada la clase del componente, que estamos
'insertando un nuevo pedido y que existe una capa logica que hace las
validaciones
'de la nueva fila insertada

No, esas validaciones le corresponden al SGBD.

Private sub On_RowChanging
' La funcion GenerarComandoInsert probablemente se basaria en el
' esquema de la tabla para interpretar lo que se desea hacer

Exacto.

Componente.GenerarComandoInsert

'En esta funcion se validaria que el datarow que se esta insertando
tenga los
'valores adecuados (pertenece a la capa logica del negocio)

No, simplemente lo generas y listo. Si hay algo mal ya te lo dirá el
SGBD.

Abusando de tu confianza te pregunto si de esta manera es como funcionaria
mas o menos?

Si, lo has entendido muy bien.

, o cuales modificaciones le harias al codigo que planteo...

Pues lo más importante es dejar al SGBD que compruebe la lógica de
negocio. Eso te ahorra un montón de código y de trabajo.

Un SGBD es un "motor" de lógica de negocio. El Modelo Relacional es
una aplicación directa de la teoría de conjuntos y la lógica de
predicados de primer orden. El éxito del Modelo Relacional se debe a
que es una idea muy buena utilizar la lógica matemática para la lógica
de negocio.


Una buena noticia es que el componente del que hablo ya está
disponible en Visual Studio 2005 y se llama TableAdapter

http://msdn2.microsoft.com/library/bz9tthwx(en-us,vs.80).aspx.

Aquí tienes un enlace con una demostración:

http://www.intsight.com/whidbeydb/whidbey.html

Creo que las ventajas quedan bastante claras :)



Saludos