Cómo evitar las cadenas de codificación rígida

Esta es una pregunta sobre las mejores prácticas de codificación. Me gustaría saber el consenso sobre cómo evitar mejor las cadenas de caracteres y los valores en una aplicación .NET. Lo que he visto hasta el momento en el que han trabajado anteriormente: los archivos .resxCómo evitar las cadenas de codificación rígida

utilizando recursos
almacenar estos valores y cadenas en App.config o web.config

que hacen un ApplicationStrings estáticos de clase y declarando todas las cadenas y valores allí:

public static class ApplicationStrings 
{ 
    #region constants 
    public const string APPLICATION_NAME = "X"; 
    public const string APPLICATION_RESOURCEMANAGER_NAME = "ResourceManagerX"; 
    public const string APPLICATION_DEFAULT_LOGFILENAME = "log.txt"; 
}

sin embargo, no es la tercera método, sólo otro hardcode? ¿Tiene sentido tener una clase así? El beneficio sería que todas las cadenas están en un solo lugar, pero ¿realmente se está evitando un hardcode?

Además, si ha desarrollado otros hábitos para esta situación, no dude en publicar.

Fuente

2011-07-16 Amc_rtty

Prefiero los campos estáticos de solo lectura sobre las constantes aquí. Las constantes son más para cosas que tendrán el mismo valor para siempre. Lo que hace que su semántica de versionamiento binario sea un poco molesta. – CodesInChaos

El principal beneficio es tener todas las cadenas en un solo lugar y solo tiene que cambiarlo para actualizar todo el programa. Si diferentes partes de tu programa usan la misma cadena y una instancia se actualiza, pero otra no, entonces tienes un problema. Esto es cierto para todos los literales, por cierto.

Y luego con los archivos de recursos existe la ventaja de i18n y l10n. Si lo necesita, pero muchas aplicaciones grandes deberían hacerlo.

Fuente

2011-07-16 22:38:50 Joey

La ventaja de los archivos de recursos es que pueden reemplazarse con otras versiones cuando sea necesario. Puede hacer eso con los archivos de código fuente, por supuesto, pero de alguna manera es más claro que son datos diferentes (i18n y l10n), no una funcionalidad diferente. – MRAB

Bueno, creo que ApplicationStrings es una buena solución

Fuente

2011-07-16 22:39:20

, en general, creo que es una buena práctica para almacenar todos los datos configurables en un archivo central de configuración por lo que todos los datos están en un solo lugar y puede ser compartida por otros aplicaciones

Fuente

2011-07-16 22:40:21 plague

Gracias por recordarme de los archivos app.config y web.config, actualicé la pregunta inicial. –

En mi opinión ApplicationSettings solo es útil si su configuración es (i) genuinamente constantes y (ii) por supuesto, verdaderamente pública. Si alguno de estos casos no es cierto, entonces esto no es ideal y su elección es volver a un archivo .config .resx

Fuente

2011-07-16 22:46:01

Cómo evitar las cadenas de codificación rígida

Respuesta

Cuestiones relacionadas