Problema con 3 capas...

30/06/2005 - 18:05 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 Maxi
30/06/2005 - 20:27 | Informe spam
Hola, dejame darte mi opinon:

Se deberia usar de cada herramienta lo mejor o sea: .NEt es un lenguaje
mucho mas potente que tsql con lo cual las cosas complejas a .net. Pero Tsql
es un lenguaje muy apto para muchas cosas, dandote un beneficio q es la
performance.

Si trabajas con Sp's bien desarrollados y delegas las cosas como corresponde
no deberias tener ningun tipo de problema. Los grandes problemas los veo
cuando se pasa al modelo extremista (todo dentro de un sp o todo fuera del
motor). Mi criterio para hacer las cosas es otro, dentro del motor lo que
corresponda y fuera lo que corresponda. La ventaja de tener Sp's dentro del
motor son muchas, pero el mal uso de estos mismos puede ser catastrofico
para el sistema (no hablo solo del soft sino del sistema en general).

Yo te cuento como lo hago, tengo mi capa de acceso a datos q mapea a mis
Sp's. Que tienen estos Sp's? depende, si la logica es simple y se puede
resolver con tql de forma facil estara ahi, si es una logica compleja donde
necesite un lenguaje mas poderoso que tsql entonces estara afuera. Pero me
he cansado de ver aplicaciones que hasta la integridad la tienen fuera de la
base porque la consideran regla de negocio, pues los problemas luego que
suceden por no pensar las cosas puede ser muy grande.

No uses tsql para lo que no fue pensado, usalo para lo que si fue pensado,
mientras puedas aislar a tu aplicacion de la base de datos es mas simple la
cosa, pensa que si usas sp los desarrolladores solo deben conocer el nombre
y los param sin importar lo que haga este por dentro. Ni hablar de como
mejoras la seguridad, la performance es considerablemente superior.

Un abrazo!!!


Salu2
Maxi


"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.



Preguntas similares