Discussion :

[angel46]

Bonjour

contexte:
Dans le cadre de mon stage, je développe en c# un outil qui affiche des résultats d'analyse sur un graphique.

je me retrouve actuellement avec l'architecture suivante:
- une IHM avec un control chart (widget graphique)
- une classe contrôleuse
- un module d'analyse

L'IHM est lié à ma classe contrôleuse de façon a appelé ses méthodes.
Les méthodes de la classe contrôleuse vérifie les données, lance l'analyse.
L'analyse retourne un objet avec une structure prédéfinit contenant les résultats. La classe controleuse retourne ses résultats à l'IHM.
Pour finir l'ihm parcours ses données avec des fonctions particulière et affiche les résultats dans son control chart.

sachant que le but de mon stage est l'analyse, mais pour l'utiliser et la visualiser il faut une ihm.

Question:
1- Est ce que le découpage que j'utilise est correcte ?
2- Je pense m'approcher du pattern MVC ou dérivé au niveau de la séparation des couches, mais du fait que je n'utilise pas le design pattern Observer est ce problématique ?

[tristan_m]

Bonjour,

Le découpage en trois parties semble bien correspondre à l'architecture MVC effectivement.

Sur le fonctionnement, votre application diffère un peu de celui suggéré par MVC.
Les principales différences viennent en effet du fait que vous n'utilisiez pas le pattern Observer.
Est-ce problématique? Pas forcément.
Si votre but est avant tout de respecter MVC "parce qu'il le faut", alors oui.
Si votre but est d'avoir une application qui correspond au besoin/cahier des charges, alors ça dépend du besoin/cahier des charges
Utiliser le pattern observer vous permettrait :

• D'avoir des vues indépendantes. En l'état, j'ai l'impression que si une nouvelle vue se connecte, elle n'aura vraisemblablement rien à afficher avant d'effectuer une requête.
• De partager l'application. Si votre application possède une base de données commune, tous les utilisateurs pourront les consulter et les modifier. Les vues des autres utilisateurs seront mises à jour en conséquence.
• Supporter les auto-modifications. Si les données dépendent du temps écoulé par exemple.
• Peut être d'autres points auxquels je ne pense pas à cet instant.

Par contre cela impose de stocker des données dans le modèle (en plus du module d'analyse), je n'ai pas l'impression que ce soit votre cas à l'heure actuelle.
A vous d'évaluer le besoin d'avoir ces fonctionnalités dans votre application.

En revanche, je peux vous conseiller d'effectuer la vérification des données, non pas par le contrôleur, mais par le modèle.
Même s'il parait logique que le contrôle des données soit effectué par le contrôleur, ce n'est en fait pas son rôle.
Le contrôleur dirige le fonctionnement de votre application, pas le contenu des données qui y circulent.

[angel46]

Je tiens déjà à te remercier pour ta réponse, qui m'éclaire déjà énormément.

Mes questions sur le mvc sont du à mon rapport de stage. Car j'essaie de parler un peu des technologie employer histoire de mettre un peu de valeur. Le but de mon stage est le développement du module d'analyse. L'ihm créé ne sera par la suite plus utilisé... comme tu le soulignes, je ne stocke pas de données à part dans mon contrôleurs associé à chacune de mes fenêtres. Celui ci se charge de fournir les bonnes données a mon analyse.

Dans ce cas, faudrait-il que je créée une classe spécialement conçu pour stocker ma liste de donnée, effectuer les opérations nécessaire dessus, et que se soit elle qui exécute l'analyse ?

J'obtiendrai donc une classe entre le contrôleur et mon module d'analyse. Le contrôleur appellerai les méthodes de cette classe une a une.

Derriere je me retrouverai toujours sans implémentation de pattern Observer... car je ne vois pas trop comment l'implémenter pour mon cas...
car ma vue affiche un coup une liste de donnée, un coup un objet de mon module d'analyse

Cordialement

[tristan_m]

Dans ce cas, faudrait-il que je créée une classe spécialement conçu pour stocker ma liste de donnée

Je n'ai pas saisi d'où venaient les données de départ.
C'est le contrôleur qui les reçoit directement (comment la vue y a-t-elle accès dans ce cas?)?
Elles sont envoyées au contrôleur par la vue?

Vous n'êtes pas forcément obligé de stocker la liste de données dans le modèle.
Elles ne seront juste pas accessibles depuis une autre vue.
Le principe est que si votre vue souhaite afficher quelque chose provenant du modèle, ce quelque chose doit être stocké dans le modèle.
Typiquement les données du Chart doivent être stockées dans le modèle puisque c'est lui qui les génère.

effectuer les opérations nécessaire dessus, et que se soit elle qui exécute l'analyse ?

Oui. Les opérations sur les données sont clairement à effectuer dans le modèle, de même que l'exécution de l'analyse.
En revanche attention à ne pas créer une classe qui va tout faire.
Une classe s'occupe du stockage, une classe s'occupe de l'analyse,
et idéalement, une classe s'occupe de traiter les demandes venant du contrôleur en effectuant les différents traitement nécessaires.

J'obtiendrai donc une classe entre le contrôleur et mon module d'analyse. Le contrôleur appellerai les méthodes de cette classe une a une.

Voir mon précédent commentaire. A vous de voir le niveau de granularité maitrisé par le contrôleur.
Est-ce qu'il se contente d'envoyer une requête globale au modèle, ou plusieurs requêtes spécialisées.
Je suis plus partisan de spécialiser le moins possible le contrôleur pour diminuer les dépendances,
mais cela implique souvent de créer une classe supplémentaire dans le modèle, uniquement dédiée à ces traitements.

Derriere je me retrouverai toujours sans implémentation de pattern Observer... car je ne vois pas trop comment l'implémenter pour mon cas...
car ma vue affiche un coup une liste de donnée, un coup un objet de mon module d'analyse

Le fait que l'IHM affiche un coup des données un coup d'autres n'est pas gênant.
Avec le pattern Observer, la vue reçoit des indications de changements, elle ne prend en compte que celles qui l'intéresse.
Typiquement pour le Chart, je suppose qu'actuellement il est affiché lorsque la réponse est reçue.
Avec le pattern Observer, le contrôleur ne va pas renvoyer de résultat (au mieux un acquittement de requête envoyée).
Une fois les données analysées, le modèle va indiquer à la vue que de nouvelles données de chart sont disponibles.
La vue peut alors "switcher" sur l'affichage chart et demander les données de chart.

Je pense que la logique derrière le "un coup - un coup" n'a pas à être modifiée.
Simplement les données à afficher arriveront d'une façon différente.

[angel46]

Les données de départ sont dans une base de donnée.
J'ai une première vue qui avec un contrôleur et une classe dao, me permet de reconstituer la liste dont j'ai besoin et qui l'envoie a ma deuxième vue.

Niveau découpage de ma vue, je n'aurai qu'une classe, qui stockerai ma liste, et qui s’occupera des 2/3 opérations a effectuer dessus.

En faite mon controle chart est déjà affiché dans ma vue mais sans aucune donnée, je le modifie grâce à une classe auquel il est associé et qui possède toute les fonctions pour gérer l'affichage, avec une fonction pour mes données brut, et une fonction pour mes donnée analysé.