Discussion :

[azstar]

Bonjour;

Je veux votre avis sur le concept suivant:

Pour un concept multi-couches: A mon avis le faite d’accéder à la configuration (app.config ou web.config ) dans les classes de la couche d'accès au données n'est pas une bonne pratique?

Je pense que la couche d’accès aux données doit avoir son rôle unique " accès aux bases de données" ,sinon on trouvera des problèmes si on veut réutiliser cette couche pour d'autre application?!!.


Je veux votre avis sur ça ?!!

Merci

[SLiM_ViNCe]

Si dans les couches autres que l'applicatif tu vas chercher de la configuration, alors tu contraints l'applicatif à se soumettre au mode de paramétrage de la couche d'accès aux données par exemple.

Il est plus souple de ne pas l'imposer, ça c'est sûr mais sur de petits projets ça reste pas complètement fou de récupérer par exemple une chaîne de connexion dans la section ConnectionStrings à mon avis...

[azstar]

Si dans les couches autres que l'applicatif tu vas chercher de la configuration, alors tu contraints l'applicatif à se soumettre au mode de paramétrage de la couche d'accès aux données par exemple.

Il est plus souple de ne pas l'imposer, ça c'est sûr mais sur de petits projets ça reste pas complètement fou de récupérer par exemple une chaîne de connexion dans la section ConnectionStrings à mon avis...

Je peux tolérer le faite de lire la configuration pour le cas des données fortement liées à la fonctionnement de ma couche, parmi elle les données de connexion (ConnectionStrings ) ;mais pour les données de configuration liées plus au métier (business logic Layer), je ne crois pas que c'est le bon endroit pour le faire ,même si que ces données peuvent être utilisés par cette couche pour faire un traitement (exemple : nombre d'essaie pour marquer une ligne en erreur)

[DotNetMatt]

Chaque couche peut aller lire la configuration lorsque nécessaire, c'est l'objectif du ConfigurationManager de .NET.

S'il y a beaucoup de CustomSections et/ou que les infos nécessitent un traitement spécifique, on peut envisager de créer un module spécifique et indépendant qui se chargera d'aller lire ces sections à la demande. Ce module sera ensuite appelé indifféremment par les différentes couches.

On peut aussi ajouter une couche "CLL" (Config Logic Layer), qui permettrait de charger les sections en mémoire par exemple au démarrage de l'appli. Puis cette couche serait interrogée par les autres lorsqu'elles en ont besoin. On peut l'intégrer ou non dans la DAL. Mais à mon avis ce scénario est surtout utile dans des cas où il y a une réelle complexité à gérer au niveau de la config.

Bref il y a pas mal de possibilités, je n'ai pas connaissance d'une best practice à ce sujet mais si quelqu'un en a, je suis preneur

[azstar]

Chaque couche peut aller lire la configuration lorsque nécessaire, c'est l'objectif du ConfigurationManager de .NET.

Je ne suis pas d'accord, ça posera de problème si ma future application n’implémente pas un fichier configuration (app.config ou web.config); par exemple si ma future application utiliser un simple fichier text, donc je suis obliger à chercher tous les endroits où j'ai mis "ConfigurationManager" pour le changer par ma nouvelle méthodes de chercher les configs,et c'est loin d’être un bon résultat de l'utilisation du concept mutli-couche ( minimiser les modifications dans réutilisation,.....).

je dis peut être faire passer les configs en paramètre pour les méthodes (couche DAL ) qui utilisent ces configs?!!

S'il y a beaucoup de CustomSections et/ou que les infos nécessitent un traitement spécifique, on peut envisager de créer un module spécifique et indépendant qui se chargera d'aller lire ces sections à la demande. Ce module sera ensuite appelé indifféremment par les différentes couches.

On peut aussi ajouter une couche "CLL" (Config Logic Layer), qui permettrait de charger les sections en mémoire par exemple au démarrage de l'appli. Puis cette couche serait interrogée par les autres lorsqu'elles en ont besoin. On peut l'intégrer ou non dans la DAL. Mais à mon avis ce scénario est surtout utile dans des cas où il y a une réelle complexité à gérer au niveau de la config.

oui, une méthode comme ça va me regrouper toutes les accès aux configs et même plus opter pour une classestatic pour charger une seul fois mes configs.

mais l'appel de cette classe (j'envisage que j'ai une seule classe de config ) se fait dans la couche DAL ,ou bien faire l'appel dans la couche métier - faire passer les paramètres aux méthodes - ?

[DotNetMatt]

Je ne suis pas d'accord, ça posera de problème si ma future application n’implémente pas un fichier configuration (app.config ou web.config); par exemple si ma future application utiliser un simple fichier text, donc je suis obliger à chercher tous les endroits où j'ai mis "ConfigurationManager" pour le changer par ma nouvelle méthodes de chercher les configs,et c'est loin d’être un bon résultat de l'utilisation du concept mutli-couche ( minimiser les modifications dans réutilisation,.....).

je dis peut être faire passer les configs en paramètre pour les méthodes (couche DAL ) qui utilisent ces configs?!!

Effectivement ça dépend des cas, mais comme tu as juste mentionné les fichiers de config classique app et web.config, je n'ai pas inclu d'éléments de réponse liés à d'autres formats

oui, une méthode comme ça va me regrouper toutes les accès aux configs et même plus opter pour une classestatic pour charger une seul fois mes configs.

mais l'appel de cette classe (j'envisage que j'ai une seule classe de config ) se fait dans la couche DAL ,ou bien faire l'appel dans la couche métier - faire passer les paramètres aux méthodes - ?

Comme je l'ai dit, je ne sais pas s'il y a des recommandations à suivre à ce sujet, mais personnellement ça ne me choque pas d'aller chercher des infos de config depuis la BLL et depuis la DAL.

Par exemple dans une appli, j'ai des noms de fichiers XML à récupérer dans mon web.config. Je n'en ai besoin que dans la BLL donc l'appel ne se fait qu'à ce niveau.

Ma DAL va aussi chercher des infos, comme par exemple les chaînes de connexion aux bases de données.

Dans un autre projet, on chargeait au démarrage l'ensemble des paramètres dans un objet spécifique, qui ensuite transitait dans toute l'application. Un peu à la façon d'un DTO alimenté par la DAL.

Après, singleton ou pas singleton, c'est à toi de voir en fonction des besoins ! Tu peux envisager d'en mettre un si les paramètres sont les mêmes pour tous les utilisateurs de l'application.

[Guulh]

Voici comment on fonctionne dans mon équipe:
- déjà, la majorité des classes sont instanciées par le conteneur IOC. On place donc les dépendances dans le constructeur.
- on crée la classe de la section de conf qui nous intéresse. (BiduleConfSection)
- on en extrait l'interface (IBiduleConf)
- la classe qui a besoin de la conf l'a en paramètre de son constructeur
- le conteneur IOC lit la conf, extrait la section, et l'enregistre.

Un exemple concret:

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
public class BiduleConfSection : ConfigurationSection, IBiduleConf
{
        [ConfigurationProperty("Module")]
        public string Module
        {
            get { return (string)base["Module"]; }
        }
}
public interface IBiduleConf { string Module { get; } }
 
public class DAO
{
  private readonly IBiduleConf conf;
  public DAO(IBiduleConf conf)
  {
    this.conf = conf;
  }
}
 
// dans la méthode d'init de l'appli
var biduleConf = (IBiduleConf)ConfigurationManager.GetSection("BiduleConf");
...
var leDaoEnQuestion = new DAO(biduleConf);

Comme ça, seule la méthode d'init lit la conf, et tes objets n'ont pas de dépendance sur le namespace System.Configuration.

[azstar]

Bonjour;

Comme je l'ai dit, je ne sais pas s'il y a des recommandations à suivre à ce sujet, mais personnellement ça ne me choque pas d'aller chercher des infos de config depuis la BLL et depuis la DAL.

Par exemple dans une appli, j'ai des noms de fichiers XML à récupérer dans mon web.config. Je n'en ai besoin que dans la BLL donc l'appel ne se fait qu'à ce niveau.

Je pense que si ces données sont utilisées pour des traitements qui ne vent pas parasiter le rôle de la couche DAL ,oui je suis d'accord mais avec une classe dédiée ou bien avec la méthode de Guulh

Sinon, je tomberai sur une traitement que doit être la faite dans la couche métier. Donc pour les configs liées au métier, logiquement, pas besoin être lu dans la couche DAL ?