Cuándo usar las constantes frente a los archivos de configuración para mantener la configuración

A menudo lucho conmigo mismo sobre si poner ciertas claves en mi web.config o en una clase Constants.cs o algo así.

Por ejemplo, si quisiera almacenar claves específicas de la aplicación para cualquier caso ... podría almacenarlo y tomarlo de mi configuración web a través de claves personalizadas o consumirlo haciendo referencia a una constante en mi clase de constantes.

¿Cuándo quieres usar Constantes sobre las teclas de configuración?

Esta pregunta realmente se aplica a cualquier idioma que pienso.

Personalmente, solo usaría constantes como valores predeterminados y dejaría que se anularan por valores de un archivo de configuración.

Si la aplicación toma argumentos de la línea de comando, estos a su vez anularían los parámetros del archivo de configuración.

El valor en el archivo de configuración es más difícil de mantener que el valor en la clase de constantes, ya que el compilador no comprueba si existe y es del tipo correcto, el IDE generalmente no proporciona asistencia con el código y también porque es otra sintaxis a la que debe cambiar mientras se programa

Entonces sugeriría poner:

• Valores que serán los mismos en todas las instalaciones como constantes en el código. Hay algunas ventajas de ponerlos en una clase de constantes (puede probar fácilmente varios valores para ver cómo funcionan) y ponerlos en el módulo que los usa (no tiene que abrir otro archivo al modificar ese módulo y evitando un archivo que todos editarían causando conflictos en el control de versiones).
• Valores que (pueden) necesitar ser cambiados por instalación al archivo de configuración. Y es probable que desee poner el valor predeterminado en el código de todos modos, por lo que si el valor no se establece en la configuración, la aplicación aún funciona (de alguna manera).

Las constantes cambiantes requieren la reconstrucción de la aplicación en la mayoría de los casos. Dicho de otra manera, las constantes siguen siendo constantes cuando alguien no tiene acceso al código.

Por lo tanto, cualquier información que el usuario final deba proporcionar (y deba cambiar) debe ir a los archivos de configuración. La mayoría de los otros necesitan ir bajo constantes. Sin embargo, debe haber valores predeterminados legítimos o manejo de excepciones de error si los archivos de configuración están rotos.

Elementos que no forman parte de la abstracción del objeto (es decir, si es probable que las constantes que no están destinadas a ser modificadas por objetos externos (de llamada) estén ocultas y esencialmente signifiquen que serían mejores como constantes privadas que los archivos de configuración.

Cuando hay muchos elementos de configuración que pertenecen a diferentes objetos, no relacionados entre sí, y cuando tantos objetos necesitan extraer archivos de configuración (iguales o propios), es probable que estas cosas hayan sido constantes.

Una regla general simple es crear constantes cuando sabes que trabajarás con un conjunto fijo de valores que sabes que se pueden aplicar a cualquier contexto dado sin necesidad de cambiar; Proporcionar configuraciones externas para todo lo demás.

Un buen ejemplo de constantes sería si todas las formas con las que trabajara pudieran ser SQUAREo ROUND. En la mayoría de los idiomas, podrá aprovechar el hecho de que este valor no cambia con el tiempo, asignándolo solo una vez y optimizando cómo se accede.

Las configuraciones externas son necesarias cuando necesite recuperar el valor dinámicamente porque no puede asumir de antemano el valor con el que trabajará, pero eso no significa que tenga que hacer una compensación de rendimiento: para los valores de configuración que espera ser En la actualidad, cuando se hace correctamente, solo paga el precio de recuperarlos una vez y aún así obtiene todos los beneficios.

También puede simplemente usar este patrón de diseño: "convención sobre configuración".

http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

Una constante por definición es una ubicación de memoria para un valor que no debería cambiar (como PI).

Supongo que quisiste decir 'parámetro' y no una constante

Además de lo que se ha dicho, tenga en cuenta que exponer las variables a la entrada del usuario desde el archivo de configuración puede dañar la aplicación.

Cuando sea posible, no exponga los valores en el archivo de configuración sin validarlos en el código para tener una verificación de cordura. Además, le sugiero que no coloque parámetros de reglas de negocio (como salario máximo, etc.) en los archivos de configuración y que tampoco use constantes para esos. Dichos valores deben almacenarse en la base de datos con las definiciones de tabla apropiadas para que se aplique cierta seguridad cuando se modifiquen y pueda crear automáticamente versiones de los valores de los datos (utilizando procesos almacenados o registros de db). Por supuesto, esto depende de cuán sensible sea su aplicación.

Si alguna vez usa archivos de configuración para almacenar datos, asegúrese de versionarlos.