Bonjour
je suis en train de faire une recherche sur l'architecture d'une application asp.net mvc4 et je n'ai rien trouvé
merci de me répondre
Version imprimable
Bonjour
je suis en train de faire une recherche sur l'architecture d'une application asp.net mvc4 et je n'ai rien trouvé
merci de me répondre
Cadeau, ça vient directement de ma formation sur ASP.Net MVC 5 :)
Pièce jointe 146318
Il y a un truc qui cloche dans ton schéma. Dans ASP.Net MVC il y a MVC et dans MVC il M pour Model. Donc ma question est simple pourquoi le bloc Model n'est pas un sous-bloc du bloc ASP.Net MVC ? Je ne parle pas du contenu du bloc Model qui est tout à fait correct.
Dans MVC il y a Modèle en effet mais celui-ci est externe à la tuyauterie du MVC lui-même.
Le principe est simple : tu as un modèle métier (souvent existant) et tu veux le projeter visuellement sans induire de couplage => tu intercales une couche de contrôle.
Cependant tu remarqueras que dans mon schéma il y a une partie modèle de vue (view-model) qui est une projection non visuelle du modèle, dans l'idéal c'est un mapping direct d'un sous-ensemble du modèle.
Donc au sein du modèle d'exécution ASP.Net MVC c'est là que tu retrouves des morceaux plus ou moins bruts du modèle métier.
Le rôle de projecteur visuel est tenu par le moteur de templates Razor qui va générer une partie de la vue.
Et d'ailleurs quand tu développes un projet MVC le modèle est toujours isolé dans son propre projet et assembly.
Même s'il n'existait pas auparavant il y a (au moins) 3 bonnes raisons :
- permettre la réutilisation future du modèle : si tu développes un nouvelle UI en client lourd (WPF, WinRT...) tu ne veux pas dépendre d'un projet ASP.Net MVC ;)
- faciliter les tests unitaires : tu as typiquement un projet de test du modèle métier et un de l'application MVC
- séparer logiquement les différentes parties de l'application est toujours une bonne pratique même si techniquement tu n'en tires pas profit : quelqu'un débarquant a tout de suite une vision plus claire de l'architecture.
J'espère que c'est clair désormais. :)
Pas besoin de toutes ces explications. Je connais le but du pattern MVC et ce que veut dire un modèle dans le pattern MVC et ce que cela apporte comme avantages. Ce qui pose problème c'est ton schéma pour expliquer le pattern d'architecture :mrgreen:Citation:
Envoyé par Pragmateek
Ta réponse à ma question c'est ça si j'ai bien compris :
MVC n'est pas une tuyauterie mais un pattern. C'est ASP.net MVC la tuyauterie pour moi.Citation:
Envoyé par Pragmateek
Citation provenant de Wikipedia (elle est à peu près la même dans tous les bouquins traitant du sujet) :
Et c'est ce que fait ton bloc Model dans ton schéma. Ce n'est pas parce que le Model existe la plupart du temps que celui-ci doit être exclus du pattern d'architecture MVC. Que ton modèle existe ou pas, quand tu implémentes MVC, alors ton modèle fait partie du M dans le MVC. Sinon les VM (View models) sont des modèles juste simplifiés. Ils sont créés la plupart du temps pour ne pas exposer trop de données à la vue (éviter l'over-posting et utilisation de AutoMapper ou EmitMapper pour mapper le modèle à la vue modèle etc) et parfois vu qu'une vue n'est associé qu'avec un seul type de modèle et que les données à afficher peuvent provenir de plusieurs modèles alors les vue-modèles viennent à la rescousse.Citation:
Envoyé par Wikipedia
Pour répondre à la question initiale de saber07 :
MVC est un pattern d'architecture. ASP.Net MVC est juste une technologie (ce n'est pas une architecture), c'est la tuyauterie intégrée à la plateforme .Net facilitant l'implémentation du pattern MVC. Il faut d'abords comprendre le but initial de MVC et une fois cela fait alors il faut étudier comment ASP.Net MVC permet de l'appliquer et cela il y a plein de site dont http://asp.net/mvc qui te faciliteront la tâche.
Donc dans ce cas on est d'accord. :)
C'est un schéma de l'architecture du framework ASP.Net MVC pas du design pattern MVC.
Donc c'est pour cela qu'il y a un bloc ASP.Net MVC avec juste sa tuyauterie (routage, contrôle et vue) qui est bien distincte du modèle.
