Aplicación C# - ¿Debo usar procedimientos almacenados o ADO.NET con técnicas de programación C#?

Question

Tengo una aplicación C# que estoy creando que almacena todos los datos en SQL Server.

A veces es más fácil para mí realizar cambios en los datos de forma programática y, a veces, es más fácil tener procedimientos almacenados y funciones en la base de datos de SQL Server y llamarlos.

Soy bastante nuevo en la programación y no sé cuáles son las sutiles ventajas y/o desventajas de cada método.

Me imagino que probablemente debería estar haciendo las cosas de una forma u otra en lugar de utilizar varios métodos.

Mi código está empezando a parecer una colección aleatoria de pensamientos todos metidos en un solo lugar. Sin ofender a Joel Spolsky. Amo sus libros.

Este es un proyecto en solitario, por lo que puedo refactorizar cualquier cantidad de código que desee para mejorarlo. Todas las opciones están sobre la mesa.

Gracias,

J3r3myK

Answer 1

Bueno, procedimientos almacenados pueden ser un nivel adicional de abstracción o un conjunto de funciones/métodos si nos fijamos en la base de datos como un objeto o servicio. Esto puede ser beneficioso, ya que puede ocultar los detalles de implementación subyacentes y cambiarlos cuando sea necesario sin interrumpir la aplicación (siempre que deje la interfaz, por ejemplo, los parámetros de proceso almacenados, solos). Además, si puede ocultar los detalles de su tabla detrás de un conjunto de procesos almacenados, no importa cómo alguien acceda a su base de datos, solo podrán interactuar con ella utilizando los métodos que diseñó y escribió para ella -> hay menos riesgo de que alguien active Excel y piratee su base de datos.

Por otro lado, Stored Proc requiere un amplio conocimiento de T-SQL y distribuirá su negocio y la lógica de la aplicación en dos conjuntos de bases de código, lo que puede ser un inconveniente. Todo lo que puede hacer en un proceso almacenado también se puede hacer en ADO.NET con instrucciones SQL directas, y ya no es más lento.

Una ventaja adicional para Stored Procs es el hecho de que si algo está mal en su proceso, puede solucionarlo simplemente implementando el proceso con la corrección; no necesita tocar su aplicación C#. Esto puede ser una gran ventaja en un entorno "alojado" si solo obtienes 3 lanzamientos por año. ¡Aplicar un Hotfix mediante la fijación de un Stored Proc puede ser tu salvavidas en ese momento! :-)

En general: hay muchos pros y contras a favor o en contra de los procesos almacenados; Sugeriría, si te sientes cómodo escribiendo T-SQL, por qué no intentarlo y ver cómo funciona para ti. Si se siente incómodo o demasiado inflexible o le gusta trabajar demasiado a la larga, siempre puede volver a usar SQL directo en su aplicación C#.

Sólo mi $ 0.02. Marc

Answer 2

Bueno, vas a terminar usando ADO.NET en cualquier caso ... parece que te refieres a los procedimientos almacenados frente al comando-texto. Desafortunadamente, hay ventajas de ambos, así que no es una pregunta simple, sin embargo, si está buscando herramientas como LINQ, hay más ventajas para el texto de comando, ya que puede ser más "composable" (es decir, el que llama puede agregue Skip/Take/Where/OrderBy y haga que afecte a la consulta general).

Otra opción que combina los beneficios de ambas son las funciones con valores de tabla (a través de UDF); también tienen la ventaja de metadatos más fuertes (es difícil consultar con precisión el esquema de un procedimiento almacenado).

Cualquier enfoque debe ser seguro para la inyección siempre que use correctamente los parámetros.

Answer 3

Permítanme expresarlo de otro modo: en caso de que se tira abajo de los datos, la modificación en el código, y luego tener una actualización de SP del DB con los nuevos valores, o en caso de que llame a la SP como una "función" .
Mi punto de énfasis es que, incluso si usted hace las manipulaciones de datos en el código, solo debería tener acceso a los SP en el db.

Tanto si hacer eso, o tienen productos especiales más complejos no la manipulación de datos, dependerá de varios factores:

• su nivel de comodidad con SQL compleja (a diferencia de C#)
• datos de cuánto necesita desplegar y modificar - puede haber aspectos de rendimiento (cuesta extraer todos esos datos al código)
• conectado al anterior, su arquitectura puede entrar en juego - por ejemplo ¿Está accediendo a un servidor db local o remota
• ¿Qué tipo de manipulaciones que hay que hacer, puede ser tan compleja que no desea enturbiar su SQL
• ¿Qué tipo de lógica de negocio que necesita para cumplir, lo que es el datos depende, etc.

Todo se reduce a una cuestión de criterio, no hay derecho manera (aunque hay muchas maneras equivocadas ...). Si bien es importante mantener la coherencia, es perfectamente aceptable tener diferentes tipos de acceso a bases de datos en su sistema, siempre que el contexto/necesidad lo justifique.
Yo diría que elija el que sea más cómodo con usted, y quédese con eso - hasta que tenga una razón para hacerlo de manera diferente. No hay razón para ser dogmático al respecto ...

Answer 4

Recomendaría seguir una de las convenciones o la otra (ya sea que tenga su código SQL como cadenas en sus clases o utilice procedimientos almacenados). Hay innumerables debates sobre esto, pero realmente no hay razones importantes para elegir uno u otro.

Answer 5

dos puntos que no han sido cubiertos todavía:

sprocs se pueden colocar en un esquema, y ​​se hacen pasar por un esquema diferente. Esto significa que puede bloquear el acceso a la base de datos y otorgar permisos a los usuarios SOLAMENTE para ejecutar sus SProcs, no para seleccionar actualizaciones, etc., que es una bonificación de seguridad muy agradable.

En segundo lugar, el sproc puede ser SIGNIFICATIVAMENTE más rápido dependiendo de las operaciones que realice. Si está restringido por IO de red y puede realizar operaciones de conjunto en sus datos, hacerlo en un solo procedimiento almacenado en lugar de hacer una búsqueda del conjunto de datos completo, procesarlo y luego transmitir el cambio le dará un buen aumento de velocidad.

Igual vale para las transacciones, si necesita realizar operaciones en serie (es decir, cambiar un valor en dos tablas a la vez que implica cierta lógica), deberá mantener una transacción durante el tiempo que le tome calcular el valor y transmitir de vuelta en dos consultas SQL, mientras que el procedimiento almacenado puede hacerlo en un solo procedimiento.