Declarar cadenas public static readonly versus public const versus public static const

Question

En cada proyecto que tenemos hay un archivo utilizado para almacenar las distintas sentencias SQL utilizadas en ese proyecto. Hay un puñado de variaciones sobre cómo se declara la clase y cómo se declaran las cadenas.

declartions Ejemplo de clase:

internal sealed class ClassName 
internal static class ClassName 
public sealed class ClassName 
public static class ClassName 
internal class ClassName 

Ejemplos de declaraciones de cadena:

internal const string stringName 
internal static string stringName 
public static readonly string stringName 
public static string stringName 
public const string stringName 

que no entienden lo que son las implicaciones de rendimiento entre las diferentes declaraciones. ¿Hay una mejor práctica para esta situación/escenario?

Answer 1

I don't understand what the performance implications are between the different declarations

El costo de la evaluación de la consulta de bases de datos es probablemente va a ser millones o mil millones de veces que la diferencia en el costo de cambiar de una constante a un campo de sólo lectura o viceversa.Ni siquiera se preocupe por el rendimiento de algo que demora un par de nanosegundos cuando tiene operaciones de base de datos que tienen latencia medida en milisegundos.

Lo que debe preocuparse es la semántica, no el rendimiento. La pregunta se reduce a "solo lectura, constante o ninguna?"

Obtener la semántica correcta. Un campo de "solo lectura" significa "este campo cambia exactamente una vez cada vez que se ejecuta este programa", desde nulo hasta su valor. Un campo "const" significa "este valor nunca cambia, no ahora, no en la próxima versión, nunca, es constante para todos los tiempos". Un campo ordinario puede cambiar el valor en cualquier momento.

Un campo readonly es algo así como un número de versión. Cambia con el tiempo, pero no cambia con la ejecución del programa. Una constante es algo así como pi, o el número atómico de plomo; es fijo, eterno, nunca cambia. Un campo ordinario es bueno para algo que cambia a lo largo del programa, como el precio del oro. ¿Cuál es tu consulta? ¿Será constante durante el transcurso de este programa, constante para todos los tiempos, o no constante en absoluto?

Answer 2

Debe elegir un modificador de acceso (public o internal) según el código que utiliza las cadenas.

• static const es un error del compilador.

• Un campo static readonly es un campo normal que no se puede establecer después del ctor estático.

• A const string se reemplazará por su valor literal en tiempo de compilación.
  Por lo tanto, proporcionará un rendimiento ligeramente mejor (ya que el tiempo de ejecución no utiliza el campo).
  Sin embargo, dado que se sustituye en tiempo de compilación, los cambios en la definición en un ensamblaje no serán recogidos por otros ensamblados hasta que sean todos recompilados.

Si su código sólo se utiliza en una asamblea, que también podría utilizar const cuerdas.
Sin embargo, si sus cadenas son utilizadas por otros ensambles (o pueden estarlo en el futuro), debe usar cadenas static readonly para mantenerlas.

También tenga en cuenta que una cadena const es en tiempo de compilación constante.
Si necesita incluir elementos como el nombre de la máquina o el nombre de usuario en la cadena, debe hacerlo static readonly.

Answer 3

En const vs sólo lectura estática:
const puede tener un mejor rendimiento ya que es una constante de tiempo de compilación
Pero por otro lado, tiene problemas con el control de versiones binario. La constante se inserta en el ensamblaje que la usa, por lo que si se cambia el conjunto que declara que se ha modificado, el otro ensamblaje debe volver a compilarse o utilizará una constante obsoleta.

Para las estructuras Normalmente utilizo una propiedad estática en lugar de un campo de solo lectura, ya que la inestabilidad puede optimizarla, pero todavía no tengo problemas de versión.

Answer 4

Speedwise la diferencia entre cadena estática pública y cadena const pública es insignificante.

En IL Es una diferencia entre

ldsfld someaddr.field 

y

ldstr "your const here" 

Aquí está la respuesta sin embargo. Al usar const, literalmente haces que tu ensamblaje use ese literal cada vez que lo usas, por lo que el ensamblado se usará con esos literales. Con estática, los "punteros" serán la ubicación central.

El mayor inconveniente se encuentra en lo siguiente: no puede ejecutar la caja del conmutador contra cadenas estáticas, pero puede contra const (como debería).

Por lo tanto, mi opinión sobre esto: si necesita usar el interruptor, debe usar usar const; si no lo haces - Prolly voy con estática.

HTH

Nikolai

Answer 5

Teniendo en cuenta que usted está utilizando Visual Studio, un pequeño beneficio para el uso de public const sobre public static readonly es la capacidad de utilizar IntelliSense "pico" en el valor const.

p. Ej. Dada :

public class Constants 
{ 
    public const string ConstString = "Visible!"; 
    public static readonly string StaticReadonlyString = "Invisible!"; 
}