2012-05-09 18 views
13

Me preguntaba si las personas podrían publicar su solución al problema actual de las bases de datos locales y las diferentes conexiones entre muchos desarrolladores en un proyecto dentro del control de código fuente.¿Cómo está todo el mundo almacenando conexiones?

Más específicamente, estoy hablando del problema en un proyecto que está en control de fuente y tiene muchos desarrolladores con una base de datos local cada uno. Cada desarrollador tiene su propia cadena de conexión (instancia nombrada, instancia predeterminada, nombre de la máquina, nombre de usuario, contraseña, etc.). Cada control anula la versión anterior y tira de los últimos resultados de la versión usando la cadena de conexión de otra persona.

Entonces, gente, ¿qué solución está utilizando para este problema? Puntos extra para explicaciones sobre por qué funciona su solución, pros y contras.

EDITAR Tenga en cuenta que esta respuesta no debe dirigirse únicamente a un entorno empresarial en el que tiene el control total de la instalación. La solución correcta debería funcionar para todos: empresas, startups y desarrolladores de código abierto.

Gracias!

Respuesta

10

Para mí, la pregunta parece implicar uno de dos resultados:

  1. Una cadena de conexión se especifica en la Web.archivo de configuración que es lo suficientemente genérico para funcionar para todas las versiones locales de la base de datos. Ha indicado que esta no es una configuración ideal en entornos donde no tiene control total.
  2. Cada desarrollador debe proporcionar su propia cadena de conexión que nunca se controla en el control de la fuente.

Algunos otros ya han cubierto el primer escenario. Use localhost y siga una convención para el nombre de la base de datos. Para la opción 2, te recomiendo que especifica una fuente de configuración que no consigue registrarse en control de fuente:

<configuration> 
    <connectionStrings configSource="connectionStrings.config"/> 
</configuration> 

EDIT:

connectionStrings.config

<connectionStrings> 
    <add name="Name" 
    providerName="System.Data.ProviderName" 
    connectionString="Valid Connection String;" /> 
</connectionStrings> 

Desde: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.80).aspx

connectionStrings.config sería un archivo en la raíz del proyecto que excluyó específicamente del control de origen. Se le solicitará a cada desarrollador que proporcione este archivo cuando trabaje localmente. Su cadena de conexión de producción podría sustituirse mediante una transformación Web.config en la compilación/implementación.

+0

¡Gran solución! Exactamente lo que estaba buscando y no sabía que era factible –

5

Todas nuestras estaciones de desarrollo están configuradas de la misma manera.

  1. Utilizamos autenticación integrada en la base de datos, por lo que no es necesario almacenar ningún usuario/contraseña.
  2. Todos usan la instancia predeterminada.
  3. Dado que todas son bases de datos locales, puede usar localhost.
  4. mismo nombre de la base

Así que una cadena de conexión podría llegar a ser:

Data Source=localhost;Initial Catalog=TheDatabaseName;Integrated Security=SSPI; 

Y todo el mundo utiliza eso.

+0

Esto funciona muy bien en un entorno empresarial. Modifiqué la pregunta para agregar más requisitos. –

+0

Creo que es justo exigir a los desarrolladores en un proyecto no empresarial que realicen alguna configuración local para preparar el propio entorno para su desarrollo. +1 – faester

+2

No creo que sea. Si participa en muchos proyectos, no puede esperar que el desarrollador tenga un entorno de desarrollo para cada proyecto. –

0

He visto varios métodos utilizados.

i) Sólo se mantiene una cadena de conexión en vivo y los desarrolladores realizar modificaciones en el módulo correspondiente y nunca un control de entrada.

ii) Un app.config se mantiene con las cadenas de conexión y es un archivo compartido como en lo que respecta al control de la fuente.

iii) En la configuración de depuración, los detalles de la cadena de conexión se pasan en la línea de comando desde el IDE.

1

Tenemos una base de datos de prueba que se ejecuta en su propio servidor. Solo se trata de datos de prueba que se replican del servidor en vivo todas las noches. Todos los desarrolladores usan esto para probar. Son datos verdaderos pero no son críticos ya que tienen un día de antigüedad. Almacenamos las cadenas de conexión en el web.config, por supuesto. Tengo una función para obtener la cadena de conexión de web.config y simplemente miro si localhost devuelve la cadena de conexión de prueba. si no, devuelve la cadena de conexión en vivo. Esto funciona para nosotros. Y simplemente no usamos bases de datos locales.

Cuestiones relacionadas