¿Dónde se deben almacenar cadenas de conexión en una aplicación asp.net n-tier

Question

La gente,

Tengo un proyecto ASP.NET que es bastante de n niveles, por espacio de nombres, pero tengo que separar en tres proyectos:. Capa de datos, nivel medio y front-end

Estoy haciendo esto porque ...

A) Parece lo que hay que hacer, y

B) Tengo todo tipo de problemas para ejecutar pruebas unitarias para ASP.NET alojada asambleas.

De todos modos, mi pregunta es, ¿dónde mantener su información de configuración?

Ahora mismo, por ejemplo, mis clases de nivel medio (que utiliza LINQ to SQL) tirar de forma automática la información de cadena de conexión desde el web.config cuando una instancia de un nuevo contexto de datos.

Si mi capa de datos está en otro proyecto puede / debe ser mediante el web.config para obtener información de configuración?

Si es así, cómo será una prueba de unidad, (típicamente en un conjunto separado) proporcionar información de configuración soch?

Gracias por su tiempo!

Answer 1

Los mantenemos en un archivo global "Configuración" que pasa a ser XML. Este archivo contiene todos los valores globales, uno de los cuales es un apuntador a la cadena de conexión adecuada servidor , así como nombre de usuario y contraseña. Luego, cuando mis aplicaciones que consumen, que ponen el catálogo específico (base de datos) que necesitan en la cadena de conexión.

Tenemos una versión del archivo para cada entorno operativo (prod, dev, puesta en escena, etc.). Luego, con dos configuraciones - ruta del archivo (con un símbolo que representa el medio ambiente) y el medio ambiente -. Puedo recoger los archivos de configuración correcta

Esto también tiene la ventaja agradable de un segundo de conmutación por error 30. simple cambio el nombre del servidor en el archivo de configuración y reinicie las aplicaciones (web) y que ha fallado una (por supuesto que tiene que restaurar los datos si es necesario).

A continuación, cuando se inicia la aplicación, se escribe la cadena de conexión correcta al archivo web.config (si es diferente). Con esto, podemos cambiar una página web de DEV a PROD cambiando el valor uno appsettings.

Answer 2

Mientras que no es demasiado, es conveniente tener en el web.config. Por supuesto, su DAL debe tener absolutamente ningún indicio de que se trata a partir de ahí.

Una buena opción es para su capa de datos que se le dará su información de configuración cuando se está llamado a hacer algo, y será llamado a hacer algo cuando una llamada web proceden en. Seguir adelante y poner la información en su web.config. En mi proyecto actual, tengo un diccionario estático de las cadenas de conexión en mi capa de datos, que debo llenar como tal en una rutina llamada de mi Global.asax:

CAPPData.ConnectionStrings(DatabaseName.Foo) = 
    ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) = 
    ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.

"La inyección" como este puede ser bueno para propósitos de prueba automatizados, dependiendo de cómo / si se prueba su DAL. Para mí, es sólo porque no quería hacer un archivo de configuración independiente.

Answer 3

Para propósitos de prueba hacer DataContext no instantiate con Héctor defecto. Pasar información de cadena de conexión al constructor.

Yo prefiero usar los marcos de la COI a la conexión a inyectar contexto de datos a continuación contexto inyectar a otras clases.