Je suis en train de construire une application ASP.NET MVC qui est lourde en clients-script, elle utilisera JSON et jQuery pour manipuler le DOM.
Je crois savoir que les deux Contrôleur API Web y Contrôleur MVC peut retourner JSON.
Compte tenu de mon scénario, dois-je utiliser un Contrôleur API Web ou un Contrôleur MVC ?
Les contrôleurs d'API Web peuvent être créés et hébergés dans n'importe quelle application ASP.NET, et pas seulement dans les applications MVC. Ainsi, une raison évidente de créer une API Web est si vous ne disposez pas d'un front-end MVC (par exemple, des services Web classiques, RESTful, hébergés par votre entreprise/organisation).
Les contrôleurs MVC s'appuient généralement sur le cadre MVC. Si vous regardez les modèles par défaut et la plupart des travaux réalisés par la communauté et vos pairs, vous remarquerez que presque tous les contrôleurs MVC sont mis en œuvre en tenant compte de la vue.
Personnellement, j'utilise des contrôleurs MVC lorsque j'ai l'intention de répondre avec une vue(), et j'utilise une API Web pour tout ce qui ne dépend pas d'une vue particulière.
Il y a bien sûr des réserves, mais de manière générale, si vous n'avez pas besoin du comportement de Model Binding de MVC, si votre service est centré sur les données et si les opérations sont centrées sur les données (par exemple, les opérations CRUD), vous aurez probablement besoin d'un "Web API Controller" plutôt que d'un "Model-View Controller". Inversement, si vos opérations sont centrées sur la vue (par exemple, fournir une page d'administration à l'utilisateur), ou si vous avez besoin de la liaison de modèle de MVC pour générer des "partiels ajax" (très peu probable), alors vous voudrez plutôt un contrôleur MVC.
Personnellement, j'utilise des contrôleurs Web API pour piloter les clients RESTful basés sur JSON, j'utilise des contrôleurs MVC pour gérer le routage de base du navigateur et la livraison de la SPA.
WebAPI sert à créer une API. Si vous voulez que quelqu'un puisse consommer votre API en XML, JSON, etc. vous pouvez créer une API Web.
Dans votre cas, vous avez seulement besoin de parler au client en JSON.
Même si votre site Web est principalement axé sur les script clients, vous utilisez toujours le contrôleur MVC ASP.NET, n'est-ce pas ? Et puisque vous avez peut-être déjà divisé logiquement vos contrôleurs en fonction des entités, il est logique d'y ajouter ces méthodes de service json plutôt que de créer une autre classe spécifiquement pour l'api web.
Donc, pour votre situation particulière (si je comprends bien), je m'en tiendrais aux contrôleurs.
Merci, y a-t-il une différence dans la façon de créer l'interface WebAPI par rapport au contrôleur ?
@flybyte oui vous devez dériver de ApiController, voir asp.net/web-api/overview/démarrer avec aspnet-web-api/
Web Api peut faire JSON, ainsi que les autres méthodes que vous citez. Les contrôleurs ne peuvent pas (proprement) être transformés en API, donc étant donné que l'utilisateur a la prévoyance de demander - je suggérerais d'utiliser la solution la plus évolutive/flexible. Ce n'est pas comme si c'était les services WCF de la vieille école, l'API web est généralement à la fois puissante et flexible. Ainsi, si vous n'avez besoin que de scénarios simples, elle reste en dehors de votre chemin. Mais vous avez la puissance nécessaire si vous en avez besoin.
La réponse se résume à la séparation des préoccupations, à l'accélération de la création de services et au recours à la convention plutôt qu'à la configuration.
La principale responsabilité des contrôleurs est de servir de coordinateur entre la vue et votre modèle, alors que la principale responsabilité des API est de travailler sur les données. Dans le cas des API, les conventions facilitent l'exécution des opérations CRUD. Voici la correspondance entre les opérations CRUD et les actions HTTP.
Ainsi, avec les API, il n'est pas nécessaire de créer des actions distinctes et de les attribuer à des actions HTTP.
Le seul problème que je rencontre avec ApiController est qu'il est basé sur le site et non sur la zone. Un site ne peut avoir qu'un seul sous-dossier apicontroller pour que vous puissiez nommer vos méthodes de contrôle. Dans certaines situations, vous pouvez vouloir dupliquer le nom du contrôleur dans différentes zones :
domaine.com/api/area1/controller1/
domaine.com/api/area2/controller1/
Je me souviens qu'il existe des paramètres de code personnalisés pour pouvoir le faire, mais cela ne fonctionne pas par défaut.
Je ne comprends pas vraiment ce que vous dites. Si vous nommez un contrôleur Area1XController, vous pouvez alors faire : domain.com/Area1X/1, créer un contrôleur : Area2XController et y accéder avec : domain.com/Area2X/1. La grande question est de savoir pourquoi vous voulez faire cela de toute façon. Le nom de la zone est abstrait, il ne dit rien à un utilisateur. Si vous avez, disons, 4 zones, il est préférable d'utiliser un nom fonctionnel.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Duplicata possible de Différence entre ApiController et Controller dans ASP.NET MVC
1 votes
Il est important de noter que cette question est spécifique à un certain contexte : l'auteur veut savoir quel contrôleur utiliser si SEULEMENT json doit être retourné. Une API REST autorise différents formats de médias en fonction de la négociation du contenu (par exemple : accepter xml, accepter json). Dans ce cas, le contrôleur WebAPI est votre meilleure option.