In che modo tutti stanno memorizzando le stringhe di connessione?

Question

Mi chiedevo se la gente potesse postare la propria soluzione al problema in corso dei database locali e delle diverse stringhe di connessione tra molti sviluppatori in un progetto all'interno del controllo del codice sorgente?

In particolare, sto parlando del problema relativo a un progetto che si trova nel controllo del codice sorgente e ha molti sviluppatori con un database locale ciascuno. Ogni sviluppatore ha una propria stringa di connessione (denominata istanza, istanza predefinita, nome macchina, nome utente, password, ecc.). Ogni check in sostituisce la versione precedente e tira i risultati della versione più recente utilizzando la stringa di connessione di qualcun altro.

Quindi, le persone, quale soluzione stai utilizzando per questo problema? Punti extra per spiegazioni sul perché la loro soluzione funzioni, pro e contro.

EDIT Tenete a mente che questa risposta non dovrebbe essere mirata solo per un ambiente aziendale in cui si ha il pieno controllo della configurazione. La soluzione giusta dovrebbe funzionare per tutti: sviluppatori aziendali, di avvio e open source.

Grazie!

Answer 1

Per me, la tua domanda sembra implicare uno dei due risultati:

1. Una stringa di connessione è specificato nel Web.file di configurazione che è abbastanza generico da funzionare per tutte le versioni locali del database. Hai indicato che questa non è una configurazione ideale in ambienti in cui non hai il controllo completo.
2. Ogni sviluppatore è tenuto a fornire la propria stringa di connessione che non viene mai verificata nel controllo del codice sorgente.

Alcuni altri hanno già coperto il primo scenario. Utilizzare localhost e seguire una convenzione per il nome del database. Per l'opzione 2, mi consiglia di specificare una fonte di configurazione che non viene controllato in controllo del codice sorgente:

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

EDIT:

connectionStrings.config

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

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

connectionStrings.config sarebbe un file nella radice del progetto escluso dal controllo del codice sorgente. Ogni sviluppatore dovrebbe fornire questo file quando lavora localmente. La stringa di connessione di produzione potrebbe essere sostituita tramite una trasformazione Web.config su build/deployment.

Answer 2

Tutte le nostre stazioni di sviluppo sono configurate un po 'allo stesso modo.

1. Utilizziamo l'autenticazione integrata nel database, quindi non è necessario memorizzare alcun utente/password.
2. Tutti utilizzano l'istanza predefinita.
3. Poiché sono tutti database locali, è possibile utilizzare localhost.
4. Stesso nome del database

Quindi una stringa di connessione potrebbe finire per essere:

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

E tutti usano questo.

Answer 3

Ho visto vari metodi utilizzati.

i) Si mantiene solo una stringa di connessione dal vivo e gli sviluppatori di apportare modifiche al modulo relativo e mai il check in.

ii) un app.config viene mantenuta con le stringhe di connessione ed è un file condiviso come per quanto riguarda il controllo del codice sorgente.

iii) Nella configurazione di debug, i dettagli della stringa di connessione vengono passati nella riga di comando dall'IDE.

Answer 4

Abbiamo un database di test che viene eseguito sul proprio server. Sono solo i dati di test effettivamente replicati dal server live ogni notte. Tutti gli sviluppatori usano questo per il test. Sono dati veri ma non critici dato che è un giorno vecchio. Ovviamente memorizziamo le stringhe di connessione nel web.config. Ho una funzione per ottenere la stringa di connessione da web.config e guardo se è localhost restituire la stringa di connessione di test. in caso contrario, restituire la stringa di connessione live. Questo funziona per noi. E noi semplicemente non usiamo i database locali.