¿Cuáles son las mejores prácticas en el formato de sql en línea con ADO.NET en C#

Question

? Sé que ha habido numerosas preguntas aquí sobre sql en línea vs procedimientos almacenados ... ¡No quiero comenzar otro así! Este es sobre sql en línea (o dinámico).

También sé que este punto se ha vuelto más o menos discutible con Linq a SQL y su Entidad marco sucesor.

Pero ... supongamos que ha elegido (o lo requieren sus superiores) para trabajar con ADO.NET normal antiguo y sql en línea (o dinámico). ¿Cuáles son entonces las mejores prácticas para esto y para formatear el sql?

Lo que hago ahora es lo siguiente: Primero me gusta crear mis sentencias de SQL en un procedimiento almacenado. Esto me da una coloración de sintaxis en SQL Server Management Studio y la capacidad de probar la consulta fácilmente sin tener que ejecutarla en código a través de la aplicación que estoy desarrollando.

Así que, mientras estoy poniendo en práctica/depuración, mi código es el siguiente:

using (SqlConnection conn = new SqlConnection("myDbConnectionString")) 
    { 
     conn.Open(); 
     using (SqlCommand cmd = conn.CreateCommand()) 
     { 
      cmd.CommandType = CommandType.StoredProcedure; 
      cmd.CommandText = "myStoredProcName"; 
      // add parameters here 
      using (SqlDataReader rd = cmd.ExecuteReader()) 
      { 
       // read data and fill object graph 
      } 
     } 
    } 

Una vez que la fase de depuración y la realización de pruebas, que cambie el código anterior como esto:

using (SqlConnection conn = new SqlConnection("myDbConnectionString")) 
    { 
     conn.Open(); 
     using (SqlCommand cmd = conn.CreateCommand()) 
     { 
      cmd.CommandType = CommandType.Text; 
      cmd.CommandText = GetQuery(); 
      // add parameters here 
      using (SqlDataReader rd = cmd.ExecuteReader()) 
      { 
       // read data and fill object graph 
      } 
     } 
    } 

Y añado un método privado adicional, por ej. GetQuery() en la que copiar/pegar todo el bloque del procedimiento almacenado de esta manera:

private string GetQuery() 
    { 
     return @" 
    SET NOCOUNT ON; 
    SELECT col1, col2 from tableX where id = @id 

    -- more sql here 
     "; 
    } 

Trabajando como esto tiene la ventaja de que puedo volver el código fácilmente para llamar al procedimiento almacenado de nuevo si tengo que depuración/actualización el código sql más tarde, y una vez hecho, puedo volver a colocar fácilmente el código sql con copiar/pegar, sin tener que poner comillas en cada línea y cosas así.

¿Es una buena práctica incluir líneas nuevas en la consulta?
¿Hay otras cosas o trucos que no he pensado que puedan mejorar este enfoque?
¿Cómo hacen ustedes cosas como esta?
¿O soy el único que todavía usa (tiene que usar) sql en línea?

Answer 1

En línea (con o sin la sintaxis literal @"...") está bien para consultas breves ... pero para algo más, considere tener el tsql como un archivo en el proyecto; ya sea como recursos integrados/resx, o como archivos planos. Por supuesto, en esa etapa, probablemente debas convertirlo en un procedimiento almacenado de todos modos ;-p

Pero tenerlo como un archivo separado obliga a la misma separación que hará que sea más fácil convertirlo en un procedimiento almacenado más adelante (probablemente solo agregando CREATE PROC etc.).

Un problema con inline: hace que sea tan tentador para alguien concatenar la entrada del usuario ... lo cual es obviamente malo (ha utilizado parámetros correctamente en el ejemplo).

Answer 2

He usado archivos de recursos .NET en el pasado. Estos fueron útiles para mantener una biblioteca de todas las consultas utilizadas en una biblioteca de códigos en particular, particularmente cuando la misma consulta podría usarse en varios lugares (sí, me doy cuenta de que esto también indica un diseño deficiente, pero a veces es necesario trabajar dentro del cuadro para ti).

Answer 3

Más allá de las sentencias SQL de una sola línea no triviales, siempre aprovecho para multilínea y hacerla constante

const string SelectMyTable = @" 
SELECT column_one 
    , column_two 
    , column_three 
    FROM my_table 
"; 

Todo esto me permite cortar y pegar al gestor de SQL para la prueba.