MVC et dépendance circulaire de projets

Bonjour,

Imaginons que nous avons trois classes simple représentant le pattern MVC.

1. MonModele
2. MonControler
3. MaVue

Idéalement, j'aurai tendance à séparer ma solution (ensemble de projets) en 3 parties (projets).

1. Business
2. Controler
3. View

• La projet de la classe "MonControleur" doit donc inclure dans ses dépendances le projet (ou dll) "View" car elle doit mettre à jour la vue. "Controler" inclut "View"
• Le projet de la classe "MaVue" doit donc incure le projet "Controler" car elle doit avertir le controlleur des évènements utilisateur. "View" inclut "Controler"

On a donc une dépendance circulaire interdite.

Comment pallier à ce problème?
Peut-être est-ce simplement ma séparation de classe qui est mauvaise ou non nécessaire ?

Merci d'avance

Salut,
Je ne comprends pas trop ce que recouvre la notion de "projet"... et donc je ne comprends pas non plus pourquoi les relations entre "composants" devraient se limiter à la seule inclusion...
Exemple:

Citation:

---

La projet de la classe "MonControleur" doit donc inclure dans ses dépendances le projet (ou dll) "View" car elle doit mettre à jour la vue. "Controler" inclut "View"

---

Au mieux, le contrôleur doit pouvoir dire aux Views existantes de se mettre a jour si nécessaire car les données du modèle on changé... Il y a moultes façons de réaliser cette mécanique (le pattern Observer est un exemple) sans couplage "fort" entre Views et Controllers....
- W

La notion de projet existe peut-être uniquement dans Visual.

Au lieu de parler de projet, on peut parler de .DLL.

Imaginons une dll contenant toutes les vues, et une dll contenant tous les contrôleurs.

La dll des vues et celles des controleurs s'inclut mutuellement. Car le controlleur d'une vue reçoit parfois (d'après certains tutos) en paramètre la vue. Et donc cela crée une dépendances circulaire.

Si j'ai bien compris ta solution est d'utiliser le pattern Observer situé dans une autre dll ?


Merci à toi

Salut,

Citation:

---

Envoyé par AsPrO

Imaginons une dll contenant toutes les vues, et une dll contenant tous les contrôleurs.

---

C'est une contrainte de déploiement qui est sans rapport avec le pattern MVC: la question serait-elle "comment interfacer controller et views s'ils sont dans les DLL différents"?

Citation:

---

Si j'ai bien compris ta solution est d'utiliser le pattern Observer situé dans une autre dll ?

---

Pour moi déployer "Views, Controllers, Model" dans des DLL différents est une solution... qui va demander des pré-requis pour être mise en oeuvre compte tenu des liens que devront avoir les différents "objets".
Quel sont les problèmes que vous cherchez à résoudre en optant pour un tel déploiement?
- W

Je cherche à regrouper, dans une dll, les classes par utilités de façon à minimiser le nombre de classes par dll.

C'est un peu comme essayer de diviser le code d'une classe trop grande en plusieurs petites classes avec un rôle par classe.

Ca me semblait évident que les contrôleurs et les vues avaient un rôle différent et devait donc être séparés.

Mais peut-être n'est ce pas judicieux ?

Merci

Salut,

Citation:

---

Je cherche à regrouper, dans une dll, les classes par utilités de façon à minimiser le nombre de classes par dll.

---

On peut considérer une DLL comme un composant de type "plugins": si vous ne changez pas les API, on peut faire évoluer la réalisation indépendamment du reste. Mais il va falloir définir une API i.e. les interfaces. Ce qui est plus ou moins facile suivant le langage, l'OS, ...

Citation:

---

C'est un peu comme essayer de diviser le code d'une classe trop grande en plusieurs petites classes avec un rôle par classe.

---

Dans ce cas, on peut se contenter de définir des interfaces. La classe originale se contente de les implémenter. Mais le lien de délégation est résolu "à la compile". Dans le cas DLL, il faudra définir l'interface - pour que çà compile - mais comme la compilation sera séparée, il va falloir recoller les bouts au chargement des DLL.

Citation:

---

Ca me semblait évident que les contrôleurs et les vues avaient un rôle différent et devait donc être séparés.

---

Ben, vous pouvez les mettre dans des fichiers sources "différents"... et même dans des DLLs différents, mais les difficultés ne seront pas les mêmes...
Note: Je ne sais pas quel GUI vous utilisez mais en général, ils proposent des classes de type Widgets qui intègrent la capture et le déclenchement des évènements. i.e. une partie de la logique du "controller". Ce n'est pas simple à séparer! Par contre, vous voudrez sans doute pouvoir tester indépendamment les actions effectuées sur le Modèle. Ce qui motive peut être un packaging séparé.

Citation:

---

Mais peut-être n'est ce pas judicieux ?

---

Dans la mesure ou il faudra de toutes façons charger les différentes DLL, ce n'est "judicieux" (à mon sens) que pour les faire évoluer indépendamment les unes des autres. Si vous ne devez pas satisfaire une telle exigence, c'est peut être compliquer les choses pour rien.
- W
PS: Ceci dit, je ne suis pas dans votre tête et sans connaître le contexte vous défendez peut être mal une très bonne idée.

Fais du MVC2 et tu n'auras pas de problème de référence circulaire

Bonjour,

Sinon dans le Pattern MVC tu rajoutes un Pattern Observer qui te permet de mettre à jour les données de la View sans que le Controller ai connaissance de la DLL de la Vue ?

http://cdelmas.developpez.com/articl...du-modele-mvc/

:)