Est-ce que l'ajout d'un service Web à mon projet ASP.NET MVC rompt tout le concept de MVC?ASP.NET MVC & Web Services
Ce service Web (WCF) dépend de la couche modèle de mon projet MVC pour communiquer avec le back-end (il me semble donc qu'il doit faire partie de la solution MVC). Dois-je l'ajouter au contrôleur ou au calque de modèle?
Il semble que vous deviez séparer votre modèle dans son propre assemblage et le référencer à partir de votre application MVC et de votre application WCF.
Si vous voulez faire des WebServices de style MVC, vous devriez peut-être utiliser MVC pour créer votre propre application REST.
Y a-t-il une raison particulière pour laquelle vous devez ajouter des services Web à votre application MVC? À moins d'une raison spécifique, vous devriez utiliser vos contrôleurs de façon RESTful comme vous le feriez pour un service Web RESTful.
Vérifiez ce post de Rob Connery pour plus d'informations: ASP.Net MVC: Using RESTful architecture
Ceci est assez vieux, mais vous pouvez avoir une réponse à une question que j'ai. Je suis sous l'impression que pour charger dynamiquement, disons, une liste déroulante avec des valeurs qui changent lorsqu'une autre liste déroulante change, j'ai besoin d'un service web. C'est comme ça que je le ferais dans webForms. Comment cela se fait-il dans MVC? – Erix
Le lien est cassé et je n'ai pas pu trouver de lien mis à jour. Le contenu est disponible sur la Wayback Machine: http://web.archive.org/web/20130119131317/http://wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture –
J'ai ajouté des services Web à ma demande et il fonctionne bien. Je ne crois pas qu'il viole MVC parce que c'est une interface alternative à votre modèle. MVC n'est pas approprié pour les services Web car les services Web n'ont pas de vue.
Les services Web peuvent être créé en utilisant MVC ainsi que des sites Web ou des flux RSS. En fait, c'est l'une des forces du concept MVC - la même action du contrôleur peut transmettre ses données à n'importe quel type de vue - le service web génère des données de sorte qu'il * est * une vue. :) – hangy
Je ne pense pas que la séparation du modèle dans son propre assemblage ait une incidence sur l'utilisation ou non de MVC, vous avez toujours un modèle. Où est-ce que c'est sans importance sûrement?
Séparer le modèle dans son propre projet ne rompt pas le modèle "MVC". Tout d'abord, c'est juste que - un modèle. L'objectif du modèle MVC est de délimiter clairement entre vos données, les gestionnaires de données et les présentateurs, ainsi que la manière dont vous les reliez entre eux. La meilleure façon de le faire est de savoir comment Seb a suggéré:
Quelque chose qui pourrait vous aider est le MVC Storefront que Rob Conery a mis ensemble. Allez voir la vidéo est ici:
Et si vous voulez regarder le code réel dans votre navigateur pour voir rapidement comment il l'a fait, rendez-vous ici: MVC Storefront Codeplex Code Browser
J'ai eu va faire ça.
Voir mon résultat à my blog
ps: Je ne crois pas que cela va briser le concept MVC tant que vous pensez qu'un service web est le modèle d'un référentiel parce que tout un service Web ne retourne un vidage XML.
Considérez les services Web et les bases de données comme étant identiques. Sous cette analogie, je pense qu'il est logique de placer vos ingteractions de service Web où vous placez votre logique de base de données.
Ne dupliqueriez-vous pas la logique du contrôleur dans le service, alors? Et en ne sauvant rien en utilisant un modèle, puisque vous finissez par écrire le code du contrôleur deux fois. –
@Rob, non parce que le code du contrôleur pour la visualisation de la page Web devrait traiter des vues et des modèles de validation, etc. Le contrôleur api reposant serait idéalement cracher json et les données de formatage. – Chev