No soy fanático de los procedimientos almacenados
Los procedimientos almacenados son MÁS fáciles de mantener porque:* No tiene que volver a compilar su aplicación C# cada vez que quiera cambiar algo de SQL
Terminará recompilándolo de todos modos cuando cambien los tipos de datos, o si desea devolver una columna adicional, o lo que sea. La cantidad de veces que puede "transparentemente" cambiar el SQL desde debajo de su aplicación es bastante pequeña en general
- Terminas reutilizando el código SQL.
Los lenguajes de programación, incluido C#, tienen esta cosa asombrosa, llamada función. ¡Significa que puede invocar el mismo bloque de código desde múltiples lugares! ¡Increíble! Luego puede colocar el código SQL reutilizable dentro de uno de estos, o si desea obtener una tecnología realmente avanzada, puede usar una biblioteca que lo haga por usted. Creo que se llaman Asignadores relacionales de objetos y son bastante comunes en estos días.
¡La repetición de código es lo peor que puede hacer cuando intenta construir una aplicación mantenible!
De acuerdo, es por eso que los procedimientos almacenados son algo malo. Es mucho más fácil refactorizar y descomponer (dividir en partes más pequeñas) el código en funciones que SQL en... ¿bloques de SQL?
Tiene 4 servidores web y un montón de aplicaciones de Windows que usan el mismo código SQL. Ahora se dio cuenta de que hay un pequeño problema con el código SQl, así que prefiere cambiar el proceso en 1 lugar o enviar el código a todos. los servidores web, reinstale todas las aplicaciones de escritorio (hacer clic una vez podría ayudar) en todos los cuadros de Windows
¿Por qué sus aplicaciones de Windows se conectan directamente a una base de datos central? Eso parece un ENORME agujero de seguridad allí mismo, y un cuello de botella, ya que descarta el almacenamiento en caché del lado del servidor. ¿No deberían conectarse a través de un servicio web o similar a sus servidores web?
Entonces, ¿impulsar 1 nuevo sproc o 4 nuevos servidores web?
En este caso es más fácil impulsar un nuevo sproc, pero en mi experiencia, el 95% de los 'cambios enviados' afectan el código y no la base de datos. Si envía 20 cosas a los servidores web ese mes y 1 a la base de datos, difícilmente perderá mucho si, en cambio, envía 21 cosas a los servidores web y cero a la base de datos.
Código revisado más fácilmente.
¿Puedes explicar cómo? No entiendo esto. En particular, dado que los sprocs probablemente no estén en el control de código fuente y, por lo tanto, no se puede acceder a ellos a través de navegadores SCM basados en la web, etc.
Más contras:
Storedprocs vive en la base de datos, que aparece en el mundo exterior como una caja negra. Cosas simples como querer ponerlas en control de código fuente se convierte en una pesadilla.
También está el tema del puro esfuerzo. Podría tener sentido dividir todo en un millón de niveles si está tratando de justificar a su director ejecutivo por qué les costó 7 millones de dólares crear algunos foros, pero de lo contrario, crear un proceso almacenado para cada pequeña cosa es solo un burro adicional para nada. beneficio.
