¿Cuál es la diferencia entre connections connections y appsettings?

Question

En una de las aplicaciones a las que me he referido, la cadena de conexión se almacena en AppSettings. Hasta ahora he estado almacenando la conexión en el elemento <connectionstring/>. Pero, ¿cuál es la forma correcta?

Así que mi pregunta es, ¿cuáles son las diferencias entre <connectionstrings> y <appsettings> en el web.config y hay alguna razón específica por la que debe o no debe ser almacenar cadenas de conexión en appsettings? ¿Hay reglas/pautas provistas a seguir? ¿O esto es completamente la elección del desarrollador?

Answer 1

Hay una diferencia fundamental entre connectionString y appSettings:

Se ven cosas diferentes. En .NET 2.0 y superior:

Un objeto connectionString es un nodo XML que tiene atributos específicos para establecer; y semánticamente se refiere a una cadena de conexión a la base de datos.

Por ejemplo, un connectionString tiene el siguiente aspecto:

<connectionStrings> 
    <clear/> 
    <add name="LocalSqlServer" 
      connectionString="Data Source=(local);Initial Catalog=aspnetdb;Integrated Security=True" 
      providerName="System.Data.SqlClient" /> 
    </connectionStrings> 

Se dará cuenta de que tiene unos atributos diferentes:

• name
• connectionString: Esta tiene una cadena específica en el interior de él, necesita un Initial Catalog, un mecanismo de seguridad (en este caso Integrated Security
• providerName

Mientras appSettings es sólo un par clave-valor definido por el usuario que le permite ... bueno ... configurar parámetros de la aplicación. Puede ser cualquier cosa:

<appSettings> 
    <add key="Mom" value="Your"/> 
    <add key="UseCache" value="True"/> 
    <add key="MapsKey" value="1234567890-AA"/> 
    <add key="SMTPServer" value="smtp.peterkellner.net"/> 
</appSettings> 

En muchos casos, no sería más que extraña para poner la connectionString en un par clave-valor como appSettings (semántica y programación). Además, haría más difícil el encrypt the connectionString when you need to.

Hay más información about this from this blog post.

Answer 2

Las cadenas de conexión generalmente se mantienen en el elemento <connectionstring/> ... y es una buena guía ya que se llama correctamente.

A veces puede utilizar un control de un tercero o un control de usuario que busque la cadena de conexión en una clave del elemento <appsettings>. Esa debería ser la única excepción a la guía.

Answer 3

Hasta donde yo sé, no hace una gran diferencia, aparte de que está en el lugar "correcto" - la principal ventaja de poner cadenas de conexión en su propia sección (encripta las cadenas de conexión. ¿correcto?) para que pueda encrypt that section sin encriptar todas las configuraciones que quiera cambiar.

Answer 4

Además, en IIS7, las cadenas de conexión se pueden mantener a través de la respectiva administración de IIS7.

Answer 5

Puede usar la sección appSettings para compartir configuraciones de aplicaciones personalizadas entre proyectos en .NET.

How to share custom application configuration settings across projects in .NET

Answer 6

En cuanto a la implementación, hay una diferencia significativa entre ellos. Al importar los paquetes de Internet para IIS:

• Las cadenas de conexión se incluirán automáticamente en el diálogo del asistente para su posterior parametrización.
• La configuración de la aplicación no estará allí por defecto. Si realmente quieres hacer eso, por favor, siga los pasos de "parametrización personalizada - Configuración de la aplicación en el archivo web.config" de Configuring Parameters for Web Package Deployment

Eso significa que, cuando se trata de la implementación, es mejor poner el medio ambiente parámetros (base de datos, caché, clave/secreto de AWS, etc.) en cadenas de conexión. Proporcionará una diferenciación explícita entre el entorno dev/staging/prod.