Gestione di stringhe di connessione di diversi sviluppatori in LINQ a SQL

Question

Con la mia origine in Subversion, si verificano problemi quando 2 computer diversi hanno stringhe di connessione differenti.

La finestra di progettazione LINQ to SQL sembra avere la stessa stringa di connessione.

È possibile per il progettista utilizzare una stringa di connessione che varia in quanto gli sviluppatori hanno configurazioni locali diverse, ma l'utilizzo effettivo nell'applicazione Web deriva da web.config?

Answer 1

Sfortunatamente, questa è un'enorme fonte di problemi con il designer LINQ to SQL. Non conosco un modo per forzare Visual Studio a non aggiungere mai una stringa di connessione predefinita quando trascini tabelle o stored procedure sulla superficie del progetto.

Abbiamo aggirare il problema così:

1. non abbiamo mai salvare le nostre password dev
2. non usiamo mai la stringa di connessione predefinito in codice quando Newing un DataContext
3. possiamo dunque "in sicurezza" ignora le stringhe di connessione multiple durante gli sprint che toccano il livello dati
4. quando le cose si attenuano/diventano più stabili, eliminiamo le stringhe di connessione dal contesto dati, utilizzando le proprietà della superficie di progettazione stessa o modificando l'XML. A quel punto, è compito del modificatore del contesto dati tenere il passo con l'eliminazione delle stringhe di connessione predefinite.

Ahimè, questa non è una situazione ideale. Speriamo che VS2010 "risolverà" questo problema.

Answer 2

Mi sono imbattuto in questo problema e ho trovato la tua domanda. Ecco la soluzione ora stiamo utilizzando:

1. utilizzare una classe di configurazione centralizzata per il recupero di valori di configurazione da una posizione particolare nel file system. Ciò consente a tutte le macchine su cui è in esecuzione il codice di utilizzare i propri valori di configurazione.

2. Creare una classe parziale per il contesto dati LINQ su SQL. Aggiungi un costruttore personalizzato che non accetta parametri e recupera la stringa di connessione al database dalla classe di configurazione sopra descritta.

Ad esempio:

public partial class MyCustomDBDataContext 
{ 
    public MyCustomDBDataContext() : 
       base(Configuration.GetDatabaseConnectionString()) 
    { 
    } 
} 

Questo dovrebbe ora risolvere il problema sia per gli sviluppatori e quando dispiegati per testare e produzione.

Answer 3

Seguendo le linee guida su How Do I? Change Connection String of datacontext default constructor from web.config, la mia applicazione ora utilizza stringhe di connessione diverse a seconda che HttpContext.Current.Request sia locale o meno.

//using System.Web.Configuration; 

partial void OnCreated() 
    { 
     //Change this condition to your needs 
     var isLocal = HttpContext.Current.Request.IsLocal; 
     this.Connection.ConnectionString = WebConfigurationManager.ConnectionStrings[isLocal ? "localConnectionstring" : "otherConnectionstring"].ToString(); 
    }