Votre avis sur l'utilisation des app.config dans les dll

**kheironn** · 10/10/2013, 11h01

Bonjour,
Lors d'une discussion entre collègue une question à été posée.
.Net prévoit que l'on peut utiliser des settings (dans les propriétés du projet) pour des dll. Cela génère donc des sections (ApplicationSettings / UserSettings) dans un fichier app.config, que l'on doit ensuite intégrer dans un web.config, dans le cas d'une appli web.

L'avantage, on peut faire un Properties.Settings.etc. pour récupérer le paramètre.

Ma question : est-ce oui ou non une bonne pratique ?

**AsPrO** · 10/10/2013, 11h12

Ta question se porte sur l'utilisation général des settings dans un fichier de configuration (app.config, web.config) ou plutot l'opposition à utiliser les propriétés settings d'un projet VS directement les rentrer nous même dans la balise <appSettings> ?

**kheironn** · 10/10/2013, 11h52

Envoyé par AsPrO

Ta question se porte sur l'utilisation général des settings dans un fichier de configuration (app.config, web.config) ?

Oui.

Personnellement, je trouve qu'ajouter des clefs dans appSetting et de faire ConfigurationManager.etc est moins bien qu'utiliser les propriétés typées.

Donc ma question porte bien sur "Faut-il utiliser les settings dans une dll ou les laisser dans l'application et passer les valeurs en paramètre de méthode ?"

Un exemple simple, où je travaille, certains utilisent le web.config avec une ConnectionString (normal) et passent de couchent en couche cette chaine jusqu'à la DAL. Je trouve plus simple de configurer directement la DAL avec cette chaine.

Chaque dll a ses propres settings et agit indépendamment de la config des autres. Il faut juste reporter le contenu de l'app.config dans le web.config...

Est-ce plus clair ?

**meziantou** · 10/10/2013, 12h05

Il y a une troisième solution non évoquée, les ConfigurationSection

**kheironn** · 10/10/2013, 12h51

Peut-être, mais là on dérive sur des aspects techniques visant à voir comment faire.

Ma question n'est pas comment, mais "est-ce bien de le faire ?"

Pour simplifier à fond : est-ce qu'une dll doit embarquer sa propre configuration ou doit-elle dépendre d'autres éléments de l'application ?

**meziantou** · 10/10/2013, 15h10

Faut-il utiliser les settings dans une dll ou les laisser dans l'application et passer les valeurs en paramètre de méthode ?

Je ne vois pas ce qu'il y a de choquant à mettre les settings dans le fichier app.config et à utiliser directement les valeurs dans la DLL.
Le Framework .NET utilise beaucoup le fichier de configuration (il suffit de voir tout ce que l'on peut mettre dans un fichier app.config ou web.config) et ça n'a pas l'air de choquer les utilisateurs.

Tu peux aussi faire un système mixe: tu utilises ce que tu trouve dans le fichier de config et l'application peut overrider les valeurs. C'est par exemple ce que tu peux faire avec la classe SmtpClient. Par défaut ça récupère les valeurs dans le fichier de config, mais tu peux spécifier les valeurs que tu souhaites à partir de l'application.

**kheironn** · 16/10/2013, 19h40

En quoi est-ce moins bien d'utiliser les app.config des dll que de passer toute la configuration dans le web/exe.config et de transmettre le paramétrage par paramètre de méthode ou constructeur? L'indépendance des couches voudrait plutôt le contraire.

**morgand** · 16/10/2013, 22h52

Bonsoir,

Si j'ai bien compris, et pour l'expliquer je vais reprendre ton exemple, tu préfères écrire en dur une ConnectionString dans une class plutôt que de l'écrire dans un fichier Web/App .config.

Et tu te demandes si cela est ou pas une bonne pratique. Je vais reformuler ta question par la suivante :

Es ce que paramétrer une application (Riche ou Légère) via le fichier app.config est une bonne pratique ?

Personnellement, je dis que "Oui". Dans un premier temps je vais répondre à ton exemple :

A un niveau Architecture ta DAL est présente pour te donner accès à une abstraction d'un source de donnée spécifique (C'est un peu compliqué dit comme ça).

Data Access Layer, est une couche d'accès aux données que se soit SGBD, XML, Binaire, Network etc.
La DAL te donne une façon spécifique de lire de la donnée venant d'une source

Mais es ce que cette source est figée dans le marbre, aujourd'hui ta source de donnée se trouve sur un MySQL Server sous la data base MyDataBase.
Et finalement ton projet prend de la valeur aux yeux des décideurs, mais le système de base de données ne leurs convient pas pour des raisons de performances et ils te payent u SQL Server 2012 qui roxxe du poney.
As tu envie de reprendre ton code, changer ta ConnectionString écrite en dure dans ta DAL et finalement recompiler (ta DAL) pour redéployer ton site ?

Et bien non, tu changes ta ConnectionString dans ton fichier de configuration d'application.

Le principe de l'appconfig te permet de rendre tes exécutions paramétrables et donc d'avoir un couplage faible entre la configuration et ton code, dit autrement ton code peut s'adapter de lui même suivant une configuration.

Je vais prendre un exemple plus bateau mais très parlent, es ce que tu crois que l'informatique en serait là aujourd'hui si à chaque fois que tu devais faire une ligne de commande il aurait fallu recompiler la ligne de commande avec tes paramètres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Compilation dir with parameters c:\
Exec dir

Alors dit comme ça c'est un peu abusé, il est plus facile de configurer une application dans un fichier de configuration que de le compiler ou de passer des arguments dans une ligne de commande.

Bon maintenant que j'ai bien défendu le truc, on pourrait dire que ça a un coup de lire un fichier XML au démarrage. Bon déjà quand tu démarres ton site internet d'entreprise je ne pense pas que ton site redémarre toutes les 10 secondes. Donc la 1/2 seconde permettant d'aller configurer lire la data dans le fichier et de la descendre à la DAL (je pense qu'on est même en dessous de la 1/2 seconde) est négligeable.

Le fichier de configuration te permet d'aller beaucoup plus loin que tout ça, je te conseille d'aller voir sur MSDN toutes les possibilités qu'apporte le fichier de configuration d'application. Ensuite tu le mets en parallèle avec la possibilité que tu as d'abstraire ton application et de faire un couplage faible entre les modules de ton application.

Donc pour résumer si quelqu'un n'a pas envie de tout lire, Oui l'utilisation du fichier de configuration est une très bonne pratique, comme tout outil il faut savoir l'utiliser, comprendre les avantages, les inconvénients, les possibilités et savoir les transposer.

Ne pas l'utiliser est pour moi une mauvaise pratique.

**moldavi** · 16/10/2013, 23h47

Bonjour.

Faut-il coder en dur "connectionString", ou faut-il mettre "connectionString" dans un fichier de config.

Je pense qu'il n'y a pas de règle, et c'est au développeur de prendre sa décision.

Personnellement, je code tout en dur, et quand un paramètre doit être configurable, je le sort du code et je le mets dans un fichier de config.

D'autres personnes diront que c'est bien de le mettre tout de suite dans un fichier de config, histoire d'anticiper.

C'est au choix du développeur. De toute façon l'une ou l'autre solution n'empêche pas le programme de fonctionner. Et si la "connectionString" ne change jamais durant la vie du logiciel, cela n'aura aucun impact.

Et puis bon la "connectionString" avec le mot de passe de la base de données dans un fichier non crypté...

**morgand** · 17/10/2013, 00h13

Envoyé par moldavi

Bonjour.

Faut-il coder en dur "connectionString", ou faut-il mettre "connectionString" dans un fichier de config.

Je pense qu'il n'y a pas de règle, et c'est au développeur de prendre sa décision.

Je ne suis pas d'accord avec toi, c'est en rapport avec les besoins. Si ton client explique qu'il doit pouvoir déployer son application sur différent site ou sur différente URL avec des bases de données différentes alors le fichier config se révèle plus qu'utile.

Dans mon explication je ne dis pas que la ConnectionString doit obligatoirement être dans le fichier de config, je dis qu'à partir du moment ou l'application doit être paramétrable, intégrable, etc. alors c'est une bonne pratique et ne pas l'utiliser serait la mauvaise pratique.

Donc pour résumer si quelqu'un n'a pas envie de tout lire, Oui l'utilisation du fichier de configuration est une très bonne pratique, comme tout outil il faut savoir l'utiliser, comprendre les avantages, les inconvénients, les possibilités et savoir les transposer.

Et se serait ne pas l'utiliser quand on en a besoin qui serait une mauvaise pratique.

**kheironn** · 17/10/2013, 16h19

@morgand
Tu ne m'as pas compris.

Tu as une archi avec 3 dll/projet, dont l'un est, par exemple, une web app.
Tu as donc, dans les propriétés des tes 3 projets, une section settings qui se retrouve dans un app.config (web.config pour la web app).
Ce que je fais, dans mon projet DAL, j'utilise des settings qui génère ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="ClassLibrary3.Properties.Settings.DllCnxStr" connectionString="Data Source=XXXXXXX;User ID=toto;Password=fjks;Unicode=True" providerName="System.Data.OracleClient" />
    </connectionStrings>
</configuration>

avec un exemple en code, c'est peut-être plus clair.

dans un autre projet j'ai ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
        <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <ClassLibrary1.Properties.Settings>
            <setting name="DllFieldOne" serializeAs="String">
                <value>Tutu</value>
            </setting>
        </ClassLibrary1.Properties.Settings>
    </applicationSettings>
    <userSettings>
        <ClassLibrary1.Properties.Settings>
            <setting name="DllFieldTwo" serializeAs="String">
                <value>Tata</value>
            </setting>
        </ClassLibrary1.Properties.Settings>
    </userSettings>
  <appSettings>
    <add key="DllKeyOne" value="My Key !"/>
    <add key="DllKeyTwo" value="My Second Key !"/>
  </appSettings>
</configuration>

et enfin dans mon web.config ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
<?xml version="1.0"?>
 
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
 
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="WebApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <connectionStrings>
    <add name="ApplicationServices"
         connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
 
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
 
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
 
    <membership>
      <providers>
        <clear/>
        <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
             enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
             maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
             applicationName="/" />
      </providers>
    </membership>
 
    <profile>
      <providers>
        <clear/>
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/"/>
      </providers>
    </profile>
 
    <roleManager enabled="false">
      <providers>
        <clear/>
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
 
  </system.web>
 
  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
  <applicationSettings>
    <WebApplication1.Properties.Settings>
      <setting name="WebFieldOne" serializeAs="String">
        <value>NafNaf</value>
      </setting>
      <setting name="WebFieldTwo" serializeAs="String">
        <value>NifNif</value>
      </setting>
    </WebApplication1.Properties.Settings>
  </applicationSettings>
</configuration>

au final, ma configuration est répartie dans plusieurs app/web.config.
Je dois fusionner les diffférents app.config dans mon web.config comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<?xml version="1.0"?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="WebApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
      <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
      <section name="ClassLibrary2.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
    <membership>
      <providers>
        <clear />
        <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" />
      </providers>
    </membership>
    <profile>
      <providers>
        <clear />
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/" />
      </providers>
    </profile>
    <roleManager enabled="false">
      <providers>
        <clear />
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
  </system.web>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
  <applicationSettings>
    <WebApplication1.Properties.Settings>
      <setting name="WebFieldOne" serializeAs="String">
        <value>NafNaf</value>
      </setting>
      <setting name="WebFieldTwo" serializeAs="String">
        <value>NifNif</value>
      </setting>
    </WebApplication1.Properties.Settings>
    <ClassLibrary1.Properties.Settings>
      <setting name="DllFieldOne" serializeAs="String">
        <value>Tutu</value>
      </setting>
    </ClassLibrary1.Properties.Settings>
  </applicationSettings>
  <appSettings>
    <add key="DllKeyOne" value="My Key !" />
    <add key="DllKeyTwo" value="My Second Key !" />
  </appSettings>
  <connectionStrings>
    <add name="ApplicationServices" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
    <add name="ClassLibrary3.Properties.Settings.DllCnxStr" connectionString="Data Source=XXXXXXX;User ID=toto;Password=fjks;Unicode=True" providerName="System.Data.OracleClient" />
  </connectionStrings>
  <userSettings>
    <ClassLibrary1.Properties.Settings>
      <setting name="DllFieldTwo" serializeAs="String">
        <value>Tata</value>
      </setting>
    </ClassLibrary1.Properties.Settings>
    <ClassLibrary2.Properties.Settings>
      <setting name="WebDllFieldOne" serializeAs="String">
        <value>NufNuf</value>
      </setting>
    </ClassLibrary2.Properties.Settings>
  </userSettings>
</configuration>

Ma question concerne l'utilisation des configuration des dll/projet de type librairie, par exemple.

Certains m'ont dit de ne pas faire ça, de faire des appSetting et de passer leur valeur depuis le web.config, via paramètre ou constructeur, jusqu'à la dll qui en a besoin.

Ma question est donc pour ne pas utiliser la configuration inhérante à chaque projet/dll ?

**moldavi** · 17/10/2013, 21h41

Re.

Envoyé par morgand

Si ton client explique qu'il doit pouvoir déployer son application sur différent site ou sur différente URL avec des bases de données différentes alors le fichier config se révèle plus qu'utile.

Je suis bien d'accord. Le client le demande, donc on le fait.

Si le client ne le demande pas, on est pas obligé de le faire, c'est au choix.

Envoyé par kheironn

Ma question est donc pour(quoi) ne pas utiliser la configuration inhérante à chaque projet/dll ?

Ceux qui te conseillent cela, préfèrent peut-être ne consulter qu'un seul fichier, plutôt qu'une multitude de fichier de config, lors d'une maintenance ?

Votre avis sur l'utilisation des app.config dans les dll

C#

Vue hybride

Discussions similaires

Partager

Partager