¿El compilador optimizará las cadenas bonitas formateadas, o se ejecutará ese código más lento que las cadenas que no están divididas de una manera legible?Bonito formato sql en código .NET, ¿rendimiento?
por ejemplo
string sql =
"select * " +
"from person " +
"where id = :id";
o
string sql = "select * from person where id = :id";
Esto es sólo un pequeño ejemplo. Ya sabes lo complicado que puede llegar el sql.
sólo tiene que utilizar: -
string sql =
@"select *
from person
where id = :id";
Esto es desde el punto de vista idéntica a la solución de una sola línea compiladores. Aunque no me sorprendería ver la concatenación de cadenas literales optimizadas por el compilador de todos modos. Sin embargo, el problema común con el enfoque de concatenación es olvidar incluir espacios en blanco al final de la cadena.
Un gran consejo sobre el uso de "@". ¡He usado el ampersand para muchas otras "cosas de cuerda", pero nunca supe que funcionó para cosas de varias líneas! – kaze
Tenga en cuenta que con la sintaxis "@" como se muestra, terminará con una cadena diferente a la original: se incluirán los retornos de carro, los saltos de línea y los espacios en blanco adicionales. Entonces su cadena será "select * \ r \ n from person \ r \ n where id =: id". En este caso, no importa mucho, pero en algunos casos la diferencia es importante. –
StackOverflow eliminó el espacio en blanco adicional de mi comentario anterior. Debería haber cinco espacios después de cada "\ r \ n". –
Puede utilizar
string s = @"SELECT *
FROM person
WHERE id = :id";
+1 por dejar que la cuerda se "pegue" a la izquierda en lugar de marcar las líneas siguientes. – Kleinux
Las constantes de cadena se pliegan en tiempo de compilación para que los dos fragmentos de código anterior son esencialmente idénticas.
si es una buena idea tener cadena SQL en línea es harina de otro costal ...
Ah - una de las verdades eternas de C#. ¿Qué es mejor, código que concatena cadenas usando + o código que no? En su caso, la respuesta depende de la versión de .NET que esté utilizando .NET1 solo podría optimizar la cadena + en una sola instrucción hasta el momento. Demasiados + en una sola cadena dieron como resultado un peor rendimiento ya que el compilador tuvo que recurrir a la creación de nuevas instancias de cadenas para manejar partes de cuerdas adicionales. Desde .NET 2, la arquitectura cambió ligeramente, y el compilador concatena múltiples instrucciones con total fluidez.
Gracias por el voto negativo - quien lo hizo. Explique por qué cree que esta respuesta es incorrecta para que todos puedan aprender de ella. –
Puede probar esto con un programa sencillo:
Console.WriteLine("a" + "b");
Usando reflector, se puede desmontar fácilmente el binario resultante. En modo Release, la IL que esto genera es:
L_0000: ldstr "ab"
L_0005: call void [mscorlib]System.Console::WriteLine(string)
So .NET optimiza las "bonitas cadenas formateadas".
Gran respuesta :) –
El compilador sin duda optimizaría la cadena cuando compile el programa para que sea igual en el código ejecutado. – Lazarus
¿Por qué está enviando respuestas como comentarios? –
Posible duplicado: http://stackoverflow.com/questions/627643/sql-formatting-tool –