Puis-je empêcher le concepteur de dbml d'ajouter une chaîne de connexion au fichier dbml ?

Question

Nous avons une fonction personnalisée AppSettings.GetConnectionString() qui est toujours appelé pour déterminer la chaîne de connexion qui doit être utilisée. Le fonctionnement de cette fonction n'a pas d'importance pour la discussion. Il suffit de dire qu'elle renvoie une chaîne de connexion et que je dois l'utiliser.

Je veux que mon DataContext LINQ to SQL l'utilise, j'ai donc supprimé toutes les informations de la chaîne de connexion du fichier dbml et j'ai créé une classe partielle avec un constructeur par défaut comme ceci :

public partial class SampleDataContext
{
    public SampleDataContext() : base(AppSettings.GetConnectionString()) { }
}

Cela fonctionne bien jusqu'à ce que j'utilise le concepteur pour glisser et déposer un tableau dans le diagramme. Le fait de faire glisser un tableau dans le diagramme entraîne plusieurs effets indésirables :

• Un fichier de paramètres sera créé
• Un fichier app.config sera créé
• Mon fichier dbml contiendra la chaîne de connexion.

Tout cela est fait avant même que je n'enregistre le fichier !

Lorsque je sauvegarde le diagramme, le fichier du concepteur est recréé et il contient son propre constructeur par défaut qui utilise la mauvaise chaîne de connexion. Bien sûr, cela signifie que mon DataContext a maintenant deux constructeurs par défaut et que je ne peux plus construire !

Je peux défaire toutes ces mauvaises choses mais c'est ennuyeux. Je dois supprimer manuellement la chaîne de connexion et les nouveaux fichiers après chaque modification !

Existe-t-il un moyen d'empêcher le concepteur d'effectuer ces modifications sans me le demander ?

EDIT

L'obligation d'utiliser le AppSettings.GetConnectionString() Cette méthode m'a été imposée assez tard dans le jeu. J'avais l'habitude d'utiliser quelque chose de très similaire à ce qu'elle génère pour moi. Il y a pas mal d'endroits qui appellent le constructeur par défaut. Je suis conscient que je devrais tous les modifier pour créer le contexte de données d'une autre manière (en utilisant un constructeur différent, une méthode statique, une usine, etc.) Ce type de changement ne serait que légèrement gênant puisqu'il ne devrait être effectué qu'une seule fois. Cependant, j'ai l'impression que c'est éluder le vrai problème. Le fichier dbml et les fichiers de configuration contiendraient toujours une chaîne de connexion incorrecte, si elle n'est pas utilisée, ce qui, au mieux, pourrait dérouter les autres développeurs.

Answer 1

Dans le concepteur de la DBML, vous pouvez cliquer avec le bouton droit de la souris sur n'importe quel espace blanc et cliquer sur Propriétés (ce n'est pas la même chose que de cliquer avec le bouton droit de la souris sur le fichier DBML et de cliquer sur Propriétés). À partir de là, développez l'option "Connexion". Définissez "Application Settings" sur False et supprimez le paramètre "Connection String". Ces paramètres sont ceux que le concepteur utilise pour créer ce constructeur par défaut.

À partir de là, vous pouvez utiliser le constructeur par défaut que vous avez créé en dehors du fichier designer.cs. Malheureusement, vous devrez répéter ce processus à chaque fois que vous ajouterez de nouvelles tables au designer. C'est ennuyeux, et je ressens votre douleur.

Answer 2

Vous pourriez utiliser quelque chose comme SqlMetal pour générer votre propre fichier de conception de DataContext, mais vous avez raison - le DataContext par défaut est assez difficile à percer.

L'autre option est d'obtenir votre DataContext à partir d'une méthode d'usine, de sorte que vous pouvez masquer le constructeur qui est effectivement utilisé. C'est encore mieux si vous le faites via un framework IoC comme Castle Windsor. Vous pourrez alors faire des choses comme :

var context = container.Resolve<DataContext>();

Answer 3

C'est un peu compliqué, mais vous pouvez ajouter un paramètre à votre constructeur (un paramètre inutilisé ?), utiliser ce constructeur partout et le constructeur par défaut créé par le concepteur ne vous posera aucun problème.