Version imprimable
Bonjour,
Je viens de finir un projet PHP, projet réalisé suivant le modèle MVC (Models-Vues-Controleurs) avec Zend-Framework. Je suis vraiment impressonné par l'éfficacité de cette façon de programmer.
Je désire alors faire maintenant un projet C# en MVC. Mais je n'ai aucune idée de comment l'implémenter. Alors s'il y a des bonnes volontés pour me donner un coup de pousse, j'en serai vraiment ravi.
Merci d'avance pour vos apports
ok ZaaN. Merci pour le lien. Je vais de ce pas voir comment je peux l'exploiter.
T'es en ASP.NET (si oui, poster dans le bon sous-forum aurait été intéressant...)?
Si oui, tu as le MVC framework pour ASP.NET de MS aussi.
Non Ditch, je suis en Windows Forms. J'espère que dans l'avenir, MS nous fera le plaisir d'intégrer un framework MVC pour Win Forms aussi :D
Je ne sais pas ce que tu attends d'un "framework MVC" comme tu dis, mais MVC c'est une architecture logicielle, ce n'est pas un objet ou je ne sais quoi.
Tu n'as pas besoin d'un framework pour faire du MVC, c'est simplement une manière d'organiser ton code.
Un MVC simple en winforms, c'est simplement une fenêtre qui utilise un objet controleur pour récupérer/enregistrer X instances de tes objets pauvres à partir de ta source de données.
Et pourtant :Citation:
Envoyé par SaumonAgile
Voir ce post. J'ai regardé les vidéos, ça a l'air pas mal du tout !Citation:
Envoyé par Ditch
Mais bon, c'est pour ASP.NET, pas Windows Forms...
Merci pour ces éclaircissements. Je vais voir les videos sur le lien que tomlev a mis. Bien qu'il s'agisse de ASP.NET, je suis intéressé. J'ai des projets en jachère en ASP.NET :) .
Pour les winfoms, je viens de downloader IngeniousMVC. Je vais voir s'il peut m'aider à atteindre mes objectifs, sinon je vais implémenter ma propre architecture en utilisant 3 projets : 1 pour mon modèle, 1 pour la partie GUI et le 3è pour mes controlleurs. Et éventuellement un dernier pour la gestion des classes communes aux précédents projets.
Et alors ? Quel est l'argument ici ? 8OCitation:
Envoyé par tomlev
Quel est le rapport entre le fait que le MVC soit un pattern qui existe depuis des lustres et le fait que Microsoft sorte un Framework qui facilite son implémentation ?
Je suis désolé mais tu peux faire du MVC sans utiliser un framework MVC...
Pourquoi?... Quel intéret de surdécouper ta solution en 1000 projets? Pourquoi ne pas découper en namespace? Pourquoi découper? il s'agit d'un design pattern, pas d'un modèle d'architecture n-tiers...Citation:
Envoyé par callo
Il te faut 3 classes minimum, ça c'est sur. Mais as tu les arguments pour m'expliquer pourquoi tu DOIS découper ta solution en 3 projets à cause de "MVC"?... :)
En 1 mot : DécouplageCitation:
Envoyé par Chubyone
Je trouve ça "abusif" de tout découper en assembly juste par soucis de "découplage"
Je vais pas découper tous mes patterns en x assemblies juste parce qu'il contient x parties...
Je voulais donc savoir pourquoi "3", et pas 2? un gui et un (modèle + controller)
Et pourquoi pas 4? Avec un projet définissant les controllers et un autre contenant leurs implémentations concrètes?...
Je voulais connaitre le raisonnement de 3 parties = 3 assemblies, qui me paraissait un peu simple....
Mon détecteur de mauvaise foi s'emballe ;)
Comment tu fais le jour ou tu veux déplacer la partie controleur sur un serveur avec une couche de service au milieu ?
Tu copies les fichiers dans un nouveau projet ? ;)
On n'a jamais parlé de séparer en assembly dès qu'on utilise un pattern, il ne faut pas tout mélanger. On dit simplement que c'est une bonne chose de garder à l'esprit que le MVC sert justement à découpler au maximum les systèmes, et que prévoir un minimum les évolutions des besoins, ça n'a jamais fait de mal à personne.
Je voulais savoir d'où provenait ce chiffre "3" ; puisque pour moi il y 3, 4 ou plus d'assemblies, mais pas découpé obligatoirement 1 couche MVC = 1 assembly.Citation:
Envoyé par SaumonAgile
Pour moi le découpage se fait plutôt au niveau des namespaces, qui d'ailleurs se chevauchent sur plusieurs assemblies.