Discussion :

[StormimOn]

Bonjour,

Le "problème" qui s'offre à moi est le suivant. J'ai différents projets dans la même solution, un projet principal qui référence les autres projets (librairies de classes). Je cherche à passer des informations (liées à la configuration/paramètrage et donc chargées au démarrage) entre ces projets.

Les solutions possibles que j'entrevois sont :

• Utiliser une classe statique dans une librairie "commune"
• Utiliser le fichier app.config

Pour ce qui est de la classe statique, faire un projet juste pour une classe (car la partie commune s'arrête là en ce qui me concerne) me semble excessif.
Avec le fichier app.config défini sur le projet principal, je peux accéder aux données depuis tous les projets et je serais tenté de passer par cette solution.

J'aimerais avoir vos avis et expériences sur cette problématique

[maitrebn]

Personnellement, j'ai eu la même problématique ...

J'ai fait une classe qui accède au fichier Config

Au départ, il est vrai que je n'avais qu'une seule classe mais petit à petit, je m'en suis servi pour centraliser des services qui étaient commun entre les différents librairies ...

Il y a toujours une ou deux choses que tu fais deux fois ...

Maintenant, il y a une 10zaines de classes qui centralise pas mal de services et c'est très pratique

[Roshdy]

question pertinente !
Je voudrais juste rappeler que derrière chaque fichier de conf app.config ou le web.config, il y a une classe statique ! Certes dans ce cas la classe statique (tester et valider par MS ) sera dans le startup project et non pas dans une librairie commune.
Donc c’est recommandé de passer par les fichiers de conf par défaut ! Mais pour des besoins spécifiques, comme utilisation des framworks se basant sur des fichiers de conf, la c’est intéressant de créer une classe statique pour gérer la conf / paramétrage de cette couche. Et dans ce cas je crois que c’est mieux de créer cette classe là ou la framework est utilisée ; sauf si tu prévois de changer la framework qui est chose rare, dans ce cas le besoin de créer une librairie pour la conf / param devient pertinent !

[Mose]

T'as aussi la méthode de la propagation.

Si ton archi respecte le N-tiers, tu as des couches empliées les unes sur les autres.
Les infos se trouvent dans la couche la plus basse.
Les couches au dessus peuvent y accéder et fournissent des accesseurs à ces données, pour les couches qui se trouve au dessus d'elle.

Pure curiosité : c'est quoi tes données partagées ?

[StormimOn]

Pure curiosité : c'est quoi tes données partagées ?

Ce sont des données que l'on m'envoie depuis une application externe (en appelant mon application en mode console). C'est donc mon projet principal qui lit ces informations, et comme il référence les autres projets (et non l'inverse) et que ces projets utilisent les informations passées au tout début, il faut que je fasse passer les informations d'une manière ou d'une autre.

Le système avec le app.config fonctionne très bien, donc je vais probablement rester là dessus.

[dg78]

Bonjour,

Coïncidence, j'ai le même souci (et je crois ne pas être le seul).
Je pensais qu'il aurait pu exister une solution facile, mais non. En fait tout est question de références entre les projets.

Prenons le cas du projet A qui référence les projets B et C et le projet C rérérençant D.

Le projet A voit les variables des autres projets par contre B ne voit pas les variables de A (à moins que la variable ne soit passée dans la signature d'une méthode de B). Le projet B ne peut pas référencer A sinon il y aurait une référence croisée (dépendance circulaire) ce que Visual Studio interdit.

Le projet B ne voit pas les variables de C à moins d'ajouter une référence entre B et C. On revient alors au même problème : B verra C mais C ne verra pas B.
En jouant sur ces références on peut faire passer certaines variables d'un projet à un autre mais il faut tenir compte que cela fonctionne dans un sens mais pas dans l'autre et faire attention aux références circulaires (qui peuvent exister pas seulement entre 2 projets mais entre plusieurs projets : si A référence B qui lui référence C, alors C ne peut pas référencer A).

Le plus simple est bien sür d'avoir un projet commun, référencé par tous les autres projets, et de mettre les variables à partager dans ce projet en static (ou shared en VB).

Plusieurs remarques sur la solution du app.config :
- c'est tout simplement l'utilisation d'un fichier intermédiaire servant à mémoriser les données (ou variables) que l'on veut faire passer d'un projet à un autre : le projet A écrit dans ce fichier (et le crée s'il n'existe pas) et les autres projets le relit et éventuellement écrit de nouvelles données ou des données modifiées.
- il est tout à fait possible d'utiliser d'autres types de fichiers, par exemple, un fichier texte sérialisé par un projet et désérialisé dans un autre ou tout simplement de transiter par une base de données
- si on retient la mémorisation dans app.config, c'est le app.config du projet principal. VS copie ce app.config dans le répertoire bin du projet principal et le re renomme NomDeMonAppli.exe.config.
Les autres projets peuvent avoir un app.config qui leur est propre (le cas en VB) mais ce app.config ne sert que pour la saisie, en mode design, des paramètres et des ressources, le tout étant ensuite intégré dans My.Project.Settings.Designer.vb (ou Resources) puis utilisable avec My.
- Le problème avec le app.config c'est que c'est un fichier XML donc modifiable et visible (à moins de crypter les valeurs des variables).

Un dernier mot concernant le message de Roshdy :

"Mais pour des besoins spécifiques, comme utilisation des framworks se basant sur des fichiers de conf, la c’est intéressant de créer une classe statique pour gérer la conf / paramétrage de cette couche. Et dans ce cas je crois que c’est mieux de créer cette classe là ou la framework est utilisée ; sauf si tu prévois de changer la framework qui est chose rare, dans ce cas le besoin de créer une librairie pour la conf / param devient pertinent !"

Je n'y comprends rien.
- qu'est ce qu'un "framworks se basant sur des fichiers de conf"
- comment peut on : "changer la framework"
Là cela demande un décriptage.

Cordialement

Dominique

[Mose]

En développement N-tiers, ce genre de problème n'existe pas.

Les données sont dans les couches basses, et elles sont propagées vers les couches hautes (metier puis interface) uniquement en fonction des besoins.
Tout est question d'architecture.

[genki]

Alors je suis d'accord que l'architecture N-Tiers règle beaucoup de choses mais elle ne solutionne pas le problème ci dessous.

J'ai 3 application

1. appli principale qui fait un traitement
2. appli secondaire qui permet de rejouer le traitement
3. appli de configuration qui permet d'éditer la configuration des 2 autres applis

ma question est la suivante ... comment permettre a mon application de configuration d'éditer les fichiers de config des autres appli (j'ai la solution) et comment les autres appli peuvent recharger le fichier de conf dans leur contexte ...

[undersnt]

Je suis personnellement friand du model

A reference B,
B reference C et
A et B reference D qui est une classe contenant les objets de base...

C'est d'ailleurs sur ce modele que j'ai des problemes...

J'ai un appli N-couches (d'ailleurs, je vous reprend sur l'utilisation du terme N-tiers qui ne signifie pas la même chose que N-couches), divisée comme suit :

- une couche Web
- une couche BL (couche business)
- une couche DAL (couche d'accès)
et une couche Model contenant mes objets ...


Web utilise BL qui utilise DAL et BL et DAL utilisent Model...jusque là facile...
Ca se corse...

Dans ma couche Model, je crée mes objets, dont certains (pour simplification) contiennent des attributs qui doivent être tirés de la base (Aïe)...donc cela signifie qu'ils doivent utiliser des méthodes de la DAL... (Aïe 2)...

La, je me dis bon , pas grave on va faire des classes partielles et définir une partie de ma classe dans la couche model, et redéfinir la partie ayant besoin de ma base dans la couche DAL.

Comme je suis quelqu'un de propre , je fais 1 projet par couche, dans des assembly différentes...

Forcement mon objet OBJ1 que j'ai crée partiellement dans mes 2 projets ne marche pas!! ALors bon, allez qu'à cela ne tienne, on a qu'à mettre les 2 projets dans la même assembly (mais tjr 2 projets séparés)(bah oui je suis quand meme toujours un peu propre.... )...Bon bah non ca ne marche pas...

Alors bon...la solution ultime? tout mettre dans un seul projet, et faire de l'asp? si quelqu'un a deja été face à ce probleme je suis preneur!!

merci d'avoir écouté mes problèmes existentiels!

[Mose]

Question :
- C'est quoi la différence entre ta couche métier et ta couche modèle ? Le modèle ne fait pas parti du métier ? Pour moi c'en est le coeur...

A mon humble avis, je pense que ton problème vient de ce distingo.
Si tu fusionnes modèle et business tu résouds tes pb.
Si tu fais une couche transversale, tu brises l'indépendance des couches...

[Kelpan]

Tu créés un projet X référencé par tous les projets.
Par exemple tu as 5 Projet A, B, C, D, E
A référence X
B référence X
C référence X
D référence X
E référence X

A reçoit les données de config/params qui sont stockées sous X.
Les autres projets ont accès à X, donc aux données params/Config.

[Thomas Lebrun]

Moi, je suis passé par cette solution dans mon projet:

Utiliser une classe statique dans une librairie "commune"


Cela fonctionne très bien, aucun pb

[mr.net]

je confirme les dire de Thomas
l'utilisation des classes statique dans une librairie "commune"

regle bien le probleme

[superfly]

Tres interessant ce topic.

J'ai plus ou moins le meme genre de problematique.

undersnt, ta couche model est en fait une couhe de serialization du resultat de ta DAL, en gros elle remplace l'ADO.NET, si c'est ca il n'y a aucun raison de la lie a la base.

[hed62]

Au risque de dire une enorme betise, pourquoi ne pas utiliser les webservices de WCF ? Trop lourd à mettre en place ? Vous n'etes pas en 3.0 ?

[cinemania]

je vois pas vraiment ce que les webservices et WCF viennent faire ici.

ils ne solutionnes aucunement son probleme, pire il en ajoute encore une couche, car faut configurer leur accès, et dans quelle partie...

moi je passe par une classe statique qui fait un peu office d'hébergeur de configuration.
dans la mesure ou j'ai des trucs avec pleins de threads partout, sachant que chacun appartient à un contexte différent (files pour les messages de sortie, différentes) ma classe de config, tiens donc un vrai état civil des threads et de leur "contexte" de configuration qui s'il peut etre modifié, ne doit pas modifier celui des autres.

si t'aime pas les classes statiques, une classe en singleton fait exactement la meme chose... à un détail, avec le singleton faudra penser à le rendre Thread-Safe et l'accès à l'instance sera plus long que d'utiliser directement une classe statique, qui existe systematiquement pendant toute l'exécution du programme, vu qu'elle n'a pas d'instance.
avec le singleton c'est à l'initiative de l'appelant que la classe lira la configuration, avec la classe statique, pour peu que ce soit dans son constructeur, et ca sera directement juste après le chargement et juste avant l'exécution de ton main()
dans le singleton meme dans le constructeur la configuration ne sera lue qu'a la première instanciation de l'objet.
Reste à voir où tu tiens à mettre ta configuration, et la priorité qu'elle occupe pour toi par rapport aux autres systèmes.

moi je passe par la classe statique, car mon systeme peut perdre autantde temps qu'il faut pour s'initialiser, mais ne doit plus perdre de temps du tout, une fois le main commencé...

[jerome.fortias]

Le jeton XML...
J'ai eu cette problématique à résoudre. Dans ma solution j'ai un portail et une séries d'éxécutable... N'ayant pas à gérer des processus synchrones, j'utilise un système de message par XML. Dans mon cas il s'agit de piloter des programmes d'importation de données et d'avoir un monitoring de l'activité. Pour cela chaque application laisse des jetons XML qui sont traités par une application centrale qui elle même est interfacer au portail dans un module d'interface utilisateur...Et réciproquement.

[Kaneda Shotaro]

Moi aussi j'ai un peu ce problème sauf que je souhaiterai faire dialoguer 2 application ensemble "en temps réel". Dès que l'application A envoie un message à B il faudrait que celui-ci le récupère et inversement.
J'avais pensé à un hook afin d'envoyer des messages mais je ne trouve rien sur le web à part des hook de souris et ce n'est pas ce qui m'intéresse. J'avais effectivement pensé à faire une librairie commune mais comment faire pour que les2 applications utilisent la même instance de la librairie et non pas en créer chacun une ?

Merci.