Discussion :

[Awery2]

Bonjour,

J'ai une solution à programmer, vue l'ampleur du projet, il est susceptible d'être repris par plusieurs personnes. Pour une "modélisation" assez simple pour tous j'ai choisi de développer avec la méthode MVC.

J'ai très bien compris les concepts de vues et des modèles. Par contre j'ai une question sur les contrôleurs. (Je connais bien l'objet)

Admettons l'exemple suivant :

class.animal.cs (avec mes constructeurs, méthodes de classes etc)
vue.animal.cs (mon form avec mes textes area etc)
ctrl.animal.cs (le fameux contrôleurs de mon module des animaux)

dans ma class.animal.cs :
Je fais mes traitements, base de donnée etc

dans ma vue.animal.cs
Je fais mon affichages mes champs et tout

Puis dans le contrôleurs je fais quoi exactement ?
(je sais que c'est la vue qui appelle le ou les contrôleurs correspondant et travail avec la couche métier, le ou les classes)

Dans vue.animal.cs je fais un new ctrl.animal ?

pour que ma vue fais un get de la classe animal faut bien instancier un animal ? c'est qui qui le fait ?

J'ai bien chercher 2/3 heures sur internet 90% des mvc ce font avec les technologies web...

Croyez en ma recherche.

Je vous remercie de toutes vos réponses

Amicalement Guillaume

[theMonz31]

bonjour

un exemple ici : ICI

Mon avis perso:

MVC et Winforms ==> Inutile...

et si tu lis les commentaires de certains développeurs chevronnés, ils ont tendance à aller dans ma direction...

En règle général, je dis souvent que les design patterns, c'est plutôt bien mais, avant de penser pattern, il faut penser : application...

Pourquoi mettre du MVC si j'en ai pas vraiment besoin ? C'est plus lourd à mettre en place qu'un "dev classique"...

donc, méfiance quand même !!!

[Awery2]

Je te remercie pour ton message.

Il est vrai que j'ai regarder pas mal de tuto en ASP et en JSP (je ne programme pas dans ces langues là)

Je me suis bien renseigner sur le MVC sur le langage JAVA (qui ressemble un peut au C# dans sa conception).

J'aimerai que tu développe un peut (pour ma culture) "MVC et Winforms ==> Inutile..." Pourquoi ?

Merci pour ton lien je vais lire tout ça.

Le problème majeur, c'est que si je fais de l'MVC de "mauvaise" qualité, les prochains développeur (il y en aura), seront carrément gêner.

Merci

Amicalement
Guillaume

[theMonz31]

Pour développer rapidement (mais je ne lance pas un débat)

Je ne suis pas fan du MVC quand on fait du winform et qu'il s'agit de petits projets (j'appelle un petit projet un projet ou il y a Max 2/3 développeurs à travailler
dessus en même temps)..

Le but du MVC est de séparer IHM du fonctionnel... ok, c'est bien mais ça demande de faire de la tuyauterie de lien pour celà et ça peut, si on suit la théorie
à la lettre ralentir l'application puisque l'IHM doit passer par le controleur pour se mettre à jour.

Perso, j'aime autant travailler avec un bon vieux modèle à couche (BLL - Business Layer, DLL - DataLayer, etc...) en winforms.. c'est tout aussi efficace,
tout aussi propre et beaucoup plus rapide..

Après, moi au niveau développement, j'ai des habitudes un peu particulière qui sont les suivantes:

Quand je commence un programme, ma principale question est de faire un truc qui marche... l'aspect réutilisation, etc n'est pas mon souci principal.
Je suis payé pour faire un logiciel qui marche.. donc, objectif version 1 ==> Avoir un truc qui marche bien... et non, avoir une belle architecture... (et je trouve
que bcp de dev te sortent des design patterns en veux tu en voilà, etc... avant de penser à ce qu'il faut réaliser)...

Après, En Winform, tu as les event de l'IHM qui peuvent très bien appeler des méthodes ==> Classes Métier qui font le boulot...
Et rien n'empeche l'IHM de s'abonner à des informations remontées par les classes métiers...

MVC == Plus de boulot au début... et vu que je fais des "petits" programmes modestes et beh, MVC ==> I don't give a shit

Voilà...

Peut-etre un peu basique comme réaction mais, comme je l'ai dit, m'en fout de la beauté de l'architecture... je me focalise sur l'application...

Je sais faire des applications modulaires, à base de plug-in etc... mais pourquoi irais-je mettre en place une archi à base de plug-in pour une application qui
n'en aurait besoin que SI et SEULEMENT SI le client voulait rajouter xxx options...

Je ne mets pas une batterie de 200V dans ma voiture juste au cas ou dans 10 ans yen aura besoin... je préfère utiliser ce dont j'ai besoin et si, à un moment
donné je me rends compte (en avançant dans le projet) qu'il faut faire évoluer l'architecture, je le fais...

Bref, je fais de l'agile sans le dire...

J'ai divergé un peu mais bon...

[Awery2]

J'ai eu une autre vision du MVC par un de mes anciens profs

Je prend en compte ton message, j'ai maintenant deux "point" de comparaison.

Mon projets n'est pas assez grand pour être en pattern MVC. Je vais quand même essayer quelques teste cependant pour dire "j'ai déjà essayé".

Tu as répondu en quelque sorte à ma question.

(Les prochains visiteurs de ce topic vont être dessuent => Désolé d'avance <3 )