Alternatives à l'utilisation de web.config pour stocker les paramètres (pour les solutions complexes)

Question

Dans nos applications Web, nous séparons nos couches d'accès aux données dans leurs propres projets.

Cela crée des problèmes liés aux paramètres.

Etant donné que le DAL devra éventuellement être utilisé par plusieurs applications, web.config ne semble pas être un bon endroit pour conserver les chaînes de connexion et certains des autres paramètres associés au DAL.

Pour résoudre ce problème, nous avons introduit un troisième projet uniquement pour les paramètres dans certains de nos projets récents. Nous avons mis les paramètres dans un système de fichiers .Setting ... Avec un simple wrapper, il était facile d’avoir différents paramètres pour différents environnements (Dev, Assurance qualité, Staging, Production, etc.).

Le seul problème est que le projet de paramètres (y compris la classe .Settings) est compilé dans un assemblage. Vous ne pouvez donc pas le modifier sans créer / déployer, et certains de nos clients souhaitent pouvoir configurer leur projets sans Visual Studio.

Alors, y a-t-il une meilleure pratique pour cela? J'ai l'impression de réinventer la roue.

Certaines solutions, telles que le stockage des paramètres dans un répertoire fixe sur le serveur, par exemple dans notre propre format XML, nous sont parvenues. Mais encore une fois, je préférerais éviter de recréer le cryptage pour les valeurs sensibles, etc. Et je préférerais que la solution soit autonome si possible.

MODIFIER: La question initiale ne contenait pas la véritable raison pour laquelle nous ne pouvons pas (je pense) utiliser Web.config ... Cela met quelques (très bonnes) réponses hors contexte. , mon mauvais.

Answer 1

Séparez-le. Utilisez la solution de fichier de stockage XML fixe pour la connexion à la base de données, chiffrée avec les fonctions de chiffrement intégrées de .NET (ne lancez pas la vôtre). Ensuite, en utilisant la connexion de base de données résultante, recherchez votre "table de paramètres" dans la base de données. De cette façon, vous pouvez modifier vos paramètres sans redéployer. Si vos clients doivent pouvoir modifier la chaîne de connexion à la base de données sans Visual Studio, écrivez simplement une petite application Windows Forms capable de générer la chaîne de connexion cryptée et d'enregistrer le fichier de stockage XML fixe, et si nécessaire, vous pouvez également vous connecter. dans la base de données (via ce même fichier) et modifiez le tableau des paramètres selon les besoins de l'utilisateur.

Answer 2

System.Configuration.ConfigurationManager.ConnectionStrings et System.Configuration.ConfigurationManager.AppSettings Contient les paramètres de l’application en cours d’exécution afin que vous puissiez obtenir dans le DAL les paramètres stockés dans votre fichier web.config.

Pour votre système, vous pouvez créer une section de configuration personnalisée qui se trouvera dans votre fichier web.config ou dans le fichier consumer * .config de votre DAL. Dans ces fichiers de configuration, vous pouvez spécifier qu'ils se chargent à partir d'un fichier de configuration distinct de votre conception et de votre emplacement. . Référencement de fichiers de configuration externes à partir de Web.Config Comment: créer des sections de configuration personnalisées à l'aide de ConfigurationSection

Vous pouvez également charger manuellement vos données de configuration DAL à partir de n’importe quel fichier à l’aide de ConfigurationManager.OpenExeConfiguration

Answer 3

Vous pouvez ajouter l'équivalent à un fichier web.config appelé app.config qui est compilé dans un fichier nommé pour le projet dll ou exe de votre code. Ceci est complètement modifiable sans avoir à recompiler. Vous pouvez utiliser les paramètres standard pour les chaînes de connexion et divers paramètres d'application pouvant être définis dans une paire clé / valeur - ou avec un peu plus de travail, vous pouvez définir votre propre classe et section de paramètres de configuration personnalisés. Vous pouvez même référencer les paramètres dans la configuration de votre application - vous pouvez donc avoir 3 paramètres stockés dans votre application (DEV, QA, PROD), puis ne faire référence qu'à celui que vous voulez au moment de l'exécution dans votre fichier app.config. Voici un exemple de celui créé pour un paramètre de service Web.

<? xml version = " 1.0 " encoding = & "; utf-8 &";? >
< configuration >
& nbsp; & nbsp; < configSections >
& nbsp; & nbsp; & nbsp; & nbsp; &; sectionGroup name = & "applicationSettings &"; type = ". System.Configuration.ApplicationSettingsGroup, System, Version = 2.0.0.0, Culture = neutre, PublicKeyToken = b77a5c561934e089 " >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < section name = " {Project} .Properties.Settings " type = ". System.Configuration.ClientSettingsSection, System, version = 2.0.0.0, Culture = neutre, PublicKeyToken = b77a5c561934e089 " requirePermission = " faux " / >
& nbsp; & nbsp; & nbsp; & nbsp; < / sectionGroup >
& nbsp; & nbsp; & nbsp; & nbsp; &; section name = & "; microsoft.web.services3 &"; type = " Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, version = 3.0.0.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35 " / >
& nbsp; & nbsp; < / configSections >
& nbsp; & nbsp; < applicationSettings >
& nbsp; & nbsp; & nbsp; & nbsp; < {Projet} .Properties.Settings >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < paramètre name = & "; {SettingName} &" ; serializeAs = " Chaîne " >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < valeur & ; {SettingValue} & Lt; / value & Gt;
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < / setting >
& nbsp; & nbsp; & nbsp; & nbsp; < / {Projet} .Properties.Settings >
& nbsp; & nbsp; < / applicationSettings >
& nbsp; & nbsp; < microsoft.web.services3 >
& nbsp; & nbsp; & nbsp; & nbsp; < sécurité >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < securityTokenManager >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & l; ajoutez type = quot; Microsoft.Web.Services3.Security.Tokens.UsernameTokenManager, Microsoft.Web.Services3, version = 3.0.0.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35 " namespace = " http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd & amp; quot ; nom_local = " Nom d'utilisateurToken " / >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < / securityTokenManager >
& nbsp; & nbsp; & nbsp; & nbsp; < / security >
& nbsp; & nbsp; < /microsoft.web.services3 >
< / configuration >

Answer 4

On dirait que vous ne comprenez pas comment fonctionne web.config / app.config, si je vous lis correctement. Disons que vous avez une structure comme celle-ci:

Projet DAL

Références:

• Quelques bibliothèques de base
• Références diverses

Classes:

• DatabaseHelper
• ObjectClass1
• ObjectClass2
• etc ...

Projet Web

Références:

• Quelques bibliothèques de base
• Projet DAL
• Références diverses

Pages:

• Default.aspx
• SomePage1.aspx
• etc ...
• Web.config

Dans votre classe DatabaseHelper, vous pouvez référencer la chaîne de connexion de la manière suivante:

string connString = ConfigurationManager
  .ConnectionStrings["myConnString"]
  .ConnectionString;

Lorsque cela se produit au moment de l'exécution, votre classe DatabaseHelper s'exécutera sous le même domaine d'application que votre page Web. Ainsi, tout appel à ConfigurationManager chargera la demande à partir du fichier web.config fourni par le projet Web.

Par conséquent, vous n'avez besoin que d'un fichier de configuration dans votre projet web / console / winforms / etc ... et vous n'avez pas à craindre d'en avoir un au moment de la conception dans chacun de vos projets de bibliothèque de classes.

Si vous exécutez votre DAL en tant que service ou en tant qu'application console distincte, vous devez alors attribuer au projet DAL son propre fichier app.config / web.config.

Answer 5

Une approche complètement différente consisterait à utiliser SQLite et à y stocker tous les paramètres de votre application. Vous pouvez protéger la base de données en question avec un mot de passe, si cela est important pour l'application, et vous pouvez créer de simples tables de propriétés / valeurs pour stocker les données.

L'utilisation de l'adaptateur SQLite ADO n'aurait besoin que d'une DLL supplémentaire dans les projets pour accéder aux paramètres et au La base de données SQLite elle-même serait accessible aux personnes qui ne souhaitent pas utiliser Visual Studio. Il existe même un plugin pour Firefox permettant d’interagir avec les bases de données SQLite.

Answer 6

Vous pouvez stocker les paramètres dans n’importe quel ancien fichier XML et utiliser XmlSerializer pour convertir votre classe en < - > de XML. Dans une autre answer , j'ai écrit du code qui vient de cette. La réponse liée sérialise une liste d'objets simples, mais elle permet également de sérialiser un grand objet de configuration.

Etant donné que XmlSerializer est sérialisé à partir de propriétés publiques, si vous ne souhaitez pas autoriser la modification des valeurs, il peut être nécessaire de rendre la classe elle-même immuable (style popsicle) ou d'avoir une façade en lecture seule placée devant le désérialisé.

C'est un truc pratique. Vous pouvez le configurer via ConfigurationManager.AppSettings [] avec sa propre section de configuration et ses références de fichiers externes, ou vous pouvez également coder en dur un nom de fichier xml spécifique par classe de configuration.

Answer 7

Jetez un coup d'œil sur sur Config.Net - Cadre de configuration le plus simple pour les développeurs .NET .

Une bibliothèque de configuration .NET complète, puissante, facile à utiliser et puissante, entièrement couverte de tests unitaires et testée à l’état sauvage sur des milliers de serveurs et d’applications.

Answer 8

Vous pouvez avoir une interface qui mappe vos paramètres et qui est utilisée sur votre DAL. Ensuite, sur l'application, vous pouvez simplement utiliser IoC pour transmettre les paramètres au DAL.

Answer 9

Si vous utilisez un framework DI (comme Unity), vous pouvez spécifier des arguments de constructeur. Donc, hypothétiquement, votre fournisseur DAL pourrait avoir un constructeur qui prend sa chaîne de connexion.

Je sais que vous ne pouvez pas appliquer de constructeurs dans les interfaces, mais nous devons nous en occuper. Je sais que le framework a quelques endroits où il y a des dépendances non parlées sur les signatures de constructeurs ...

Answer 10

Consultez DslConfig . Il semble que cela résout ce que vous recherchez.