Où les chaînes de connexion être stockés dans une application asp.net n-tier

Question

Folks,

J'ai un projet ASP.NET qui est assez n-tier, par l'espace de noms, mais je dois séparer en trois projets:. Couche de données, Middle Tier et Front End

Je fais cela parce que ...

A) Il semble que la bonne chose à faire, et

B) J'ai toutes sortes de problèmes en cours d'exécution des tests unitaires pour les assemblages hébergé ASP.NET.

Quoi qu'il en soit, ma question est, où gardez-vous vos informations de configuration?

En ce moment, par exemple, mes classes de niveau intermédiaire (qui utilise LINQ to SQL) tirer automatiquement leurs informations de chaîne de connexion du web.config lors de l'instanciation un nouveau contexte de données.

Si ma couche de données est dans un autre projet peut / devrait-il être à l'aide du web.config pour plus d'informations de configuration?

Si oui, comment un test unitaire, (généralement dans un ensemble séparé) fournir des informations de configuration soch?

Merci pour votre temps!

Answer 1

Nous les gardons dans un fichier global « Paramètres » qui se trouve être XML. Ce fichier contient tous les paramètres globaux, dont l'un est un pointage de chaîne de connexion appropriée à la serveur , ainsi que le nom d'utilisateur et mot de passe. Puis, quand mes applications consomment, ils ont mis le catalogue spécifique (base de données) dont ils ont besoin dans la chaîne de connexion.

Nous avons une version du fichier pour chaque environnement d'exploitation (prod, dev, mise en scène, etc.). Puis, avec deux paramètres - chemin du fichier (avec un jeton représentant l'environnement) et l'environnement -. Je peux récupérer les fichiers de paramètres corrects

Cela a aussi l'avantage de Nice de 30 secondes basculement. simple changement du nom du serveur dans le fichier de paramètres et redémarrer les applications (Web) et vous avez échoué sur (bien sûr, vous devez restaurer vos données si nécessaire).

Ensuite, lorsque l'application démarre, nous écrivons la chaîne de connexion correcte au fichier web.config (si elle est différente). Avec cela, nous pouvons changer un site web de DEV à PROD en changeant une valeur appSettings.

Answer 2

Tant qu'il n'y a pas trop, il est pratique d'avoir dans le web.config. Bien sûr, votre DAL ne devrait avoir absolument aucune idée qu'il vient de là.

Une bonne option est pour votre couche de données à donner ses informations de configuration quand il est appelé à faire quelque chose, et il sera appelé à faire quelque chose lorsqu'un appel web entre en jeu. Allez-y et mettre les informations dans votre web.config. Dans mon projet actuel, j'ai un dictionnaire statique de chaînes de connexion dans ma couche de données, que je remplir comme si dans une routine appelée de mon global.asax:

CAPPData.ConnectionStrings(DatabaseName.Foo) = 
    ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) = 
    ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.

« Injecter » comme ça peut bon à des fins de tests automatisés, selon la / si vous testez votre DAL. Pour moi, il est juste parce que je ne voulais pas faire un fichier de configuration séparé.

Answer 3

Pour des fins de test ne instancier DataContext avec cteur par défaut. Passer info chaîne de connexion au constructeur.

Je préfère utiliser des cadres pour la connexion IoC inject au contexte de données puis contexte inject à d'autres classes.