sql y .net

03/03/2004 - 13:54 por Elena | Informe spam
Hola,
quería hacer una consulta sobre un tema que me preocupa.
En mi empresa se quiere cambiar la arquitectura, de manera que en la base de
datos ya no se programe nada, es decir no se utilizarán procedimientos
almacenados y todo lo que se necesite programar se hará en el componente en
.net. Quería saber vuestra opinión sobre si es más óptimo realizar la
programación en el componente y en la base de datos tener los objetos
básicos.

Un saludo

Preguntas similare

Leer las respuestas

#6 Eladio Rincón
03/03/2004 - 15:08 | Informe spam
Hola Elena,

me gustaría que nos comentaras un poco más cómo se ha llegado a esa decisión en tu empresa; yo opino que la bd como una capa más de tu aplicación debe ser utilizada en función de las necesidades del proyecto; no se puede establecer una regla general para realizar o no realizar procesos de negocio en procedimientos almacenados, pero siempre depende del tipo de aplicación, usuarios, equipo de desarrollo, del entorno, arquitectura, etc.

Aunque supongo que ya habrás leido mucha literatura, te recomiendo las patterns & practices de MSDN:
Enterprise Solution Patterns Using Microsoft .NET
http://msdn.microsoft.com/architect...ml/Esp.asp

sería interesante conocer por qué se ha llegado a la decisión de no utilizar procedimientos almacenados ...

Gracias,

Eladio Rincón
Torrevieja - Alicante
MCAD, SQL Server MVP
http://www.siquelnet.com

"Comparte lo que sabes, aprende lo que no sepas." FGG

"Elena" escribió en el mensaje news:e$
Mostrar la cita
#7 Yoli
03/03/2004 - 15:44 | Informe spam
¿Quién ha tenido esa idea?
Yo he visto trabajar a componentes en .NET que se han tenido que tirar abajo
y empezar de nuevo por falta de rendimiento, la mayoría del código de esos
componentes ha sido sustituido por un procedimiento almacenado, que ha
mejorado enormemente su rendimiento.

De todos modos, en tu empresa han pensado en la portabilidad del código,
pero ¿han pensado en la manera de realizar la conexión entre .NET y los
distintos gestores de bases de datos?


"Elena" escribió en el mensaje
news:e$
Mostrar la cita
de
Mostrar la cita
en
Mostrar la cita
#8 Javier Loria
03/03/2004 - 16:02 | Informe spam
Hola Elena:
Yo apoyo la opinion de Miguel de creer que es una mala desicion, aun
cuando tiene "buena intencion".
En un proyecto se deben mantener varios objetivos de diseno y rara vez
puede uno sacrificar todos los demas objetivoa para obtener un maximo de
alguno. Estoy seguro que parte de los objetivos de las aplicaciones que van
a desarrollar es seguridad, escalabilidad, desempeno, desarrollo rapido,
mantenimiento, etc. y no solo compatiblidad.
Te cuento una historia vieja, que te puede servir:
=No soy muy buen carpintero, me gusta la carpinteria pero no soy buen
carpintero. Los carpinteros usan muchas herramientas para su trabajo, tienen
varios tipos de martillos, varios tipos de serruchos, seguetas y otro
instumentos especiales. En mi caso, uso un martillo y un serrucho y con esto
casi hago todo.
CASI hago una silla, CASI hago una mesa, CASI hago un
= La moraleja es usa la herramienta adecuada, para el trabajo adecuado. El
servidor MS-SQL es un gestor de Base de Datos y el SQL es basicamente un
leguaje para recuperar y manipular los datos. Usa el SQL para lo que es
bueno. Usa VB.NET/C# .NET/C++.NET, etc, para lo que son buenos: crear
aplicaciones y componentes. Manten la logica y workflow de las aplicaciones
en componentes, y manten el acceso y manipulacion de los datos en el SQL.
Es una FALACIA pensar que porque no se escriben procedimientos
almacenados se estan independizando de la plataforma de hecho, suele ser al
contrario. Cuando los desarrolladores no usas procedimientos almacenados,
crean sentencias de SQL que incluyen en su codigo de VB/C#/C++.NET, y cuando
migran de SQL 2000 a la nueva version de SQL o a cualquier otra plataforma
lo que ocurre es que tienen que "bucear" el codigo de SQL entre los
componentes. Si quieres "independizar" tu aplicacion de la BD busca
desarrollar tus componente con un patron: "Phrase Book Design Pattern", que
mantiene el lenguaje separado. O haz lo que Visual Studio ayuda a
implementar que es crear TODO el codigo de SQL en Procedimientos
Almacenados, asi la aplicacion solo ve procedimientos si cambio la
plataforma, no debo cambiar el codigo en la aplicacion (excepto el proveedor
de Datos, Ora en vez de SQL y # en vez de @).
Si quieres mantener compatibilidad en el codigo de SQL, la solucion es
escribir codigo SQL que sea compatible entre diferentes plataformas (ANSI
SQL) y comentar y obligar a los desarrolladores a justificar las razones por
las cuales usan habilidades "especiales". Revisa la documentacion en linea
sobre:
SET FIPS_FLAGGER 'FULL'
Se requiere un arquitecto de sofware para tomar desciciones de como usar
cada una de las herramientas de desarrollo, la desicion de NO HAGAMOS
VENTANAS, SOLO PUERTAS PORQUE LAS PUERTAS SON MEJORES QUE LAS VENTANAS, no
es muy razonable.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Elena escribio:
Mostrar la cita
#9 Maximiliano D. A.
03/03/2004 - 16:11 | Informe spam
jeje muy bueno lo suyo Señor!! creo que ha puesto la realidad arriba de la
mesa y de forma muy simple :-D


Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Javier Loria" escribió en el mensaje
news:%
Mostrar la cita
van
Mostrar la cita
tienen
Mostrar la cita
esto
Mostrar la cita
El
Mostrar la cita
aplicaciones
Mostrar la cita
al
Mostrar la cita
cuando
Mostrar la cita
que
Mostrar la cita
proveedor
Mostrar la cita
por
Mostrar la cita
usar
Mostrar la cita
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 21/02/2004
Ads by Google
Search Busqueda sugerida