Verwalten der Verbindungszeichenfolgen verschiedener Entwickler unter LINQ to SQL

Leider ist dies eine große Quelle von Problemen mit dem LINQ to SQL Designer. Ich kenne keine Möglichkeit, Visual Studio zu zwingen, niemals eine Standardverbindungszeichenfolge hinzuzufügen, wenn Sie Tabellen oder gespeicherte Prozeduren auf die Entwurfsoberfläche ziehen.

Wir arbeiten das Problem so um:

1. speichern wir niemals unsere Dev-Passwörter
2. Wir verwenden niemals die Standardverbindungszeichenfolge im Code, wenn ein DataContext neu erstellt wird
3. wir können daher "sicher" die Mehrfachverbindungszeichenfolgen während Sprints ignorieren, die die Datenschicht
berühren
4. Wenn die Dinge absterben / stabiler werden, löschen wir die Verbindungszeichenfolgen aus dem Datenkontext, entweder mithilfe von Eigenschaften der Designeroberfläche selbst oder durch Bearbeiten der XML. Zu diesem Zeitpunkt liegt es an dem Modifizierer des Datenkontexts, mit dem Löschen der Standardverbindungszeichenfolgen Schritt zu halten.

Leider ist das keine ideale Situation. Hoffentlich wird VS2010 dieses Problem "beheben".

Ich bin auf dieses Problem gestoßen und habe Ihre Frage gefunden. Hier ist die Lösung, die wir jetzt verwenden:

1. Verwenden Sie eine zentralisierte Konfigurationsklasse zum Abrufen von Konfigurationswerten von einem bestimmten Speicherort im Dateisystem. Dadurch kann jeder Computer, auf dem der Code ausgeführt wird, seine eigenen Konfigurationswerte verwenden.

2. Erstellen Sie eine partielle Klasse für den LINQ to SQL-Datenkontext. Fügen Sie einen benutzerdefinierten Konstruktor hinzu, der keine Parameter akzeptiert, und ruft die Datenbankverbindungszeichenfolge aus der oben beschriebenen Konfigurationsklasse ab.

Zum Beispiel:

Dies sollte nun das Problem sowohl für Entwickler als auch für Test- und Produktionszwecke lösen.

Folgen Sie den Richtlinien auf Wie geht das? Ändern Sie die Verbindungszeichenfolge des datacontext Standardkonstruktors aus web.config . Meine Anwendung verwendet jetzt verschiedene Verbindungszeichenfolgen, abhängig davon, ob HttpContext.Current.Request lokal ist oder nicht.