Gestion des chaînes de connexion de différents développeurs sous Linq à SQL

Malheureusement, il s'agit d'une grande source de douleur avec le concepteur Linq à SQL. Je ne connais pas d'une façon de forcer le studio visuel à ne jamais ajouter une chaîne de connexion par défaut lorsque vous faites glisser des tables ou des procédures stockées sur la surface de conception.

Nous travaillons donc autour de la question:

1. Nous ne sauves jamais nos mots de passe de développement
2. Nous n'utilisons jamais la chaîne de connexion par défaut dans le code lors de la nouvelle version de DataContext
3. Nous pouvons donc "en toute sécurité" ignorer les chaînes de connexion multiples lors des sprints qui touchent la couche de données
4. Lorsque les choses meurent / deviennent plus stables, nous supprimons les chaînes de connexion du contexte de données, en utilisant des propriétés de la surface de concepteur elle-même ou en modifiant le XML. À ce stade, il appartient au modificateur du contexte de données à suivre pour supprimer les chaînes de connexion par défaut.

   Hélas, ce n'est pas une situation idéale. Espérons que VS2010 «fixera» ce problème.

J'ai couru dans ce problème et j'ai trouvé votre question. Voici la solution que nous utilisons maintenant:

1. Utilisez une classe de configuration centralisée pour récupérer les valeurs de configuration à partir d'un emplacement particulier du système de fichiers. Cela permet à chaque machine où le code est exécuté pour utiliser ses propres valeurs de configuration. P> li>

2. Créez une classe partielle pour le contexte de données LINQ vers SQL. Ajoutez un constructeur personnalisé qui ne prend aucun paramètre et récupère la chaîne de connexion de base de données de la classe de configuration décrite ci-dessus. P> LI> ol>

   Par exemple: P>

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