Discussion :

[TheCaribouX]

Suite à la lecture du post précèdant (à propos de PAC), je dois admettre que j'aurais besoin d'un peu d'aide...

J'ai tout d'abord découvert les design pattern et me suis dit que c'était très intéressant, ensuite je suis tombé sur MVC que j'ai tâché de comprendre parce qu'il me semblait bien s'adapter a mon projet; les quelques post précèdants témoignent que je me suis déja pas mal posé de questions... et que finalement j'ai fait une sorte de MVC-adapté au développement sur visual studio (j'ai toujours un ptit bug de compréhension...avec vs, c'est la forme qui estt tout d'abord avertie d'un événement et ca me trouble.. :S)

finalement, il s'avère que MVC a des ptits frères, j'en ai trouvé 3 mais je suppose qu'il y en a bien plus: MVC2, HMVC, PAC.

Quelqu'un aurait-il la bonté de me donnner l'adresse d'un site explicatif "facile" et clair ou encore me dire laquelle de ces architectures est applicable au développement sous vs (tous je pense, mais la plus "intuitive")



(ps: hed62, ca fait depuis le debut que je poste que tu m'aide, je dois vraiment te désespérer.. désolé )

[hed62]

ps: hed62...

Aucun soucis
Juste en passant :

découvert les design pattern et me suis dit que c'était très intéressant, ensuite je suis tombé sur MVC

MVC est un architectural pattern, pas un design pattern.

et que finalement j'ai fait une sorte de MVC-adapté au développement sur visual studio

Ce n'est absolument pas ce qui a été dit. Il a dit, en gros, que PAC était adapté au développement de VS, pas sur VS (à moins que ma lecture en diagonale ne me fasse dire n'importe quoi !)

[TheCaribouX]

MVC est un architectural pattern, pas un design pattern.

(ça je l'avais retenu c'est poru ça que j'ai mis un "ensuite")

Il a dit, en gros, que PAC était adapté au développement de VS, pas sur VS (à moins que ma lecture en diagonale ne me fasse dire n'importe quoi !)

Ouille, mea culpa...

mmh, alors ce que j'entendais par mon message c'était plutôt ça:
(*sent qu'il va passer pour un mec qui a rien retenu de ses anciens posts*)

sous vs c#, imaginons, je crée un bouton sur le designer, je double clique dessus, pouf, ca me crée un événement dans la form (je susi pas très callé c# alors faut m'arreter si je dis n'importe quoi..), evenement auquel est abonné mon bouton.
Version MVC, le déroulement suivant serait:
la vue averti le controleur qui lance un process dans le modele.
le modele fait quelque chose et notifie ses observateurs.
En ce qui me concerne, a la fois la vue et le controlleur sont observateurs.

La ou ca se "complique" c'est que j'ai des dialogues associés à ma vue, donc il y a une forme de hiérarchie..je crois.. c'est pour ca que je me suis intéressé au dernier post sur le PAC et donc au HMVC.

en espérant avoir été légérement plus clair


c'est pour cela que j'aurais aimé connaitre un site qui regroupe et explique ou shématise ces différents architectural patterns

[hed62]

sous vs c#, imaginons, je crée un bouton sur le designer, je double clique dessus, pouf, ca me crée un événement dans la form (je susi pas très callé c# alors faut m'arreter si je dis n'importe quoi..),

Jusque là, oui, mais vs permet aussi de faire de simple application console...

evenement auquel est abonné mon bouton.

Non, le bouton est le déclencheur. L'abonné est ton code-behind (ta fonction qui récupère l'évènement.

Version MVC, le déroulement suivant serait:
la vue averti le controleur qui lance un process dans le modele.

Là encore, mon avis diffère. Pour moi, le modele "n'est qu'un" conteneur qui gère la persistance. Il ne fait rien de métier (sauf dans les projets énormes comme celui sur lequel je suis, où mon modele est plus complexe)

le modele fait quelque chose et notifie ses observateurs.

Le controlleur fait donc quelque chose au modèle ()

En ce qui me concerne, a la fois la vue et le controlleur sont observateurs.

La vue, seule observatrice, est notifée de la modification et s'adapte.

La ou ca se "complique" c'est que j'ai des dialogues associés à ma vue, donc il y a une forme de hiérarchie..je crois.. c'est pour ca que je me suis intéressé au dernier post sur le PAC et donc au HMVC.

J'avoue ne pas pouvoir faire grand chose pour toi, ne connaissant ni PAC ni HMVC, etc.. Mais "j'ai des dialogues associés à ma vue" me semble pas net.

[TheCaribouX]

Jusque là, oui, mais vs permet aussi de faire de simple application console...

j'aimerais faire en sorte que reprendre le code soit facilité pour quelqu'un d'autre que moi, et donc, le designer est a mon avis un bon moyen de simplifier cela.

Non, le bouton est le déclencheur. L'abonné est ton code-behind (ta fonction qui récupère l'évènement.

Autant pour moi

Là encore, mon avis diffère. Pour moi, le modele "n'est qu'un" conteneur qui gère la persistance. Il ne fait rien de métier (sauf dans les projets énormes comme celui sur lequel je suis, où mon modele est plus complexe)

Je dois pas vraiment comprendre la notion de métier alors, , pour moi:
Input --> Processing --> Output
Controller --> Model --> View

enfin, c'est ce que j'ai tendance à lire sur le net, donc métier et processing sont largement différenciés je suppose? (pardon pour l'incompréhension)

La vue, seule observatrice, est notifée de la modification et s'adapte.

C'est effectivement ce sur quoi j'ai abouti comme résultat.

J'avoue ne pas pouvoir faire grand chose pour toi, ne connaissant ni PAC ni HMVC, etc.. Mais "j'ai des dialogues associés à ma vue" me semble pas net.

Pas de souci, tu m'as déjà beaucoup aidé (!) , par contre si quelqu'un pouvait m'éclairer sur PAC, HMVC, ou encore MVC2, c'est volontiers

[hed62]

Je dois pas vraiment comprendre la notion de métier alors, , pour moi:
Input --> Processing --> Output
Controller --> Model --> View

Le métier, fonctionnel, Business, c'est le regroupement de toute l'intelligence propre au domaine du client. Les règles du genre "si montant < 0 alors aggios" c'est du métier. Les règles comme "les boutons Ok sont en bas à droite" c'est pas du métier, etc..

[TheCaribouX]

Du coup j'aurais tendance à dire que la partie métier est traitée par le modèle. (j'ai tapé mvc métier modèle controleur sur google et lu en diagonale les resultat pour avoir une "impression générale").

Je vais un peu retourner à mes bouquins histoire de repotasser tout ca et voir si, finalement, développer en MVC sous vs peut peut-etre etre assez aisé...

[hed62]

développer en MVC sous vs

Encore une fois, MVC et VS n'ont rien à voir, l'un n'empéche pas l'autre, ni l'un ne facilite pas l'autre. Tu peux faire avec ou sans MVC, avec ou sans VS. VS "n'est qu'un" éditeur évolué.

Par contre MVC peut se révéler inaproprié (je n'en sais rien) selon le projet en tant que tel (sa taille, son objectif, sa cible, ses contraintes...)

[TheCaribouX]

Donc en partant du principe que mon projet ne va certainement pas devenir un enorme projet plein de modules, un critère clé dans le choix de l'architecture serait la réutilisabilité du code (la vitesse de prise en main par quelqu'un d'autre), ce critère permet-il de diffférencier les pattern cités plus haut?

(toujours personne ne connait de bonne référence?)

[Franck SORIANO]

Je dois pas vraiment comprendre la notion de métier alors, , pour moi:
Input --> Processing --> Output
Controller --> Model --> View

En fait dans le "processing" tu as deux besoins :
- Gérer les règles fonctionnelles métier.
- Gérer la logique de l'IHM : Enchaînement des écrans, conditions d'activation des commandes...

Si tu veux que le code reste clair, compréhensible, voir réutilisable, il ne faut pas mélanger ces deux besoins.

C'est pour ça que quand je conçois une appli, je préfère considérer que je développe un modèle en couches (DAO, Logique métier, IHM), puis que j'utilises le MVC pour implémenter l'IHM uniquement.

Ainsi, la couche métier contient le code fonctionnel, le code qui implémente les traitements métier.

Dans la couche IHM, je dois simplement gérer la logique de l'interface.

Donc ça donne :
- Modèle : Conteneur statique des données nécessaires au fonctionnement de l'interface (codé en C#, le modèle est une classe avec des propriétés qui déclenchent des événements lorsque les données sont modifiées). Le modèle "modélise" l'état des écrans. Les composants visuels sont bindés sur le modèle.
- Vue : Affiche les données, reçoit les interactions de l'utilisateur et les délègues au contrôleur.
- Contrôleur : Coordonne le tout, gère la logique des IHM, enchaînement des traitements, appelle la couche métier en dessous pour effectuer les traitements fonctionnels. Place les résultats dans le modèle pour que les vues se redessinent...