API Web dans la solution MVC dans un projet séparé
Je suis en train de créer un nouveau projet MVC4, et des recherches m'ont conduit à penser que la communication depuis le javascript vers le serveur est mieux réalisée maintenant via un framework API Web plutôt que par des actions de contrôleur. Ma compréhension est-elle correcte à ce sujet?
Je suppose que je peux partager tous mes attributs, etc. entre l'API Web et les contrôleurs MVC, donc, en apparence, cela ne semble pas être un changement majeur pour moi.
Lorsque je configure des applications, j'aime diviser les composants en projets. Mon plan était d'avoir un projet MVC et un projet d'API Web. Mais j'ai rencontré des problèmes. Par exemple, je me suis retrouvé avec 2 applications en tant que telles, une configuration de routage séparée, etc.
Ma question est donc la suivante: dans une application MVC, la structure de l’API Web doit-elle s’intégrer au même projet ou faut-elle séparer l’API Web en un projet distinct et contourner les problèmes?
Malheureusement, vous vous trompez à ce sujet - Je suppose que je peux partager tous mes attributs, etc., entre les contrôleurs Web API et MVC, alors, à première vue, cela ne semble pas être un énorme changement pour moi.
De nombreux concepts utilisés par Web API et MVC, bien que similaires à première vue, ne sont en réalité pas compatibles. Par exemple, les attributs de l’API Web sont System.Web.Http.Filters.Filter et les attributs MVC sont System.Web.Mvc.Filter - et ils ne sont pas interchangeables.
Il en va de même pour de nombreux autres concepts - liaison de modèle (mécanismes complètement différents), itinéraires (l’API Web utilise HTTPRoutes, pas Itinéraires, même s’ils opèrent tous deux sur le même RouteTable sous-jacent), un résolveur de dépendances (non compatible), etc. surface, sont très différents dans la pratique. De plus, les API Web n'ont pas de concept de zones.
En fin de compte, si tout ce que vous essayez d’obtenir, c’est de mettre en place un "nouveau mode de diffusion" du contenu JSON: réfléchissez-y à deux fois avant de vous engager dans cette voie. Je ne recommanderais certainement pas de refactoriser un code existant à moins que vous ne cherchiez vraiment à adopter HTTP et à créer votre application de manière RESTful.
Tout dépend vraiment de ce que vous construisez. Si vous démarrez un nouveau projet et que vous n'avez besoin que de quelques JSON pour faciliter votre application Web - si vous êtes prêt à vivre avec du code potentiellement dupliqué (comme ce que j'ai mentionné ci-dessus), l'API Web pourrait facilement être hébergée dans le même projet que ASP.NET MVC.
Je ne séparerais l'API Web dans un projet distinct que si vous allez créer une API adaptée à votre service en ligne, pouvant être utilisée par des clients externes ou par divers appareils, comme le remplissage de vos applications mobiles.
OMI, la sécurité et le déploiement devraient guider votre décision. Par exemple, si votre application MVC utilise l'authentification par formulaires mais que vous souhaitez utiliser l'authentification de base (avec SSL) pour votre API, des projets distincts vont vous faciliter la vie. Si vous souhaitez héberger votre site sur www.example.com mais héberger votre API en tant qu'api.example.com (vs. www.example.com/api), des projets distincts vous faciliteront la vie. Si vous séparez vos projets et les sous-domaines en conséquence et que vous souhaitez exploiter votre propre API de votre application MVC, vous devrez trouver comment traiter le problème Politique de même origine pour les appels côté client à votre API. Les solutions les plus courantes consistent à utiliser jsonp ou CORS (de préférence si vous le pouvez).
Mise à jour (26/03/2013): Le support officiel de CORS arrive: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
Après un certain degré d'expérience (création d'API pour les applications et pour MVC). Je fais surtout les deux.
Je crée un projet distinct pour les appels d'API provenant d'autres clients ou d'autres appareils (applications Android/IOS). Une des raisons est que l'authentification est différente, elle est basée sur des jetons (pour la conserver sans état). Je ne veux pas mélanger cela dans mon application MVC.
Pour mes appels javascript/jquery api à mon application mvc, j'aime garder les choses simples afin d'inclure une api Web dans mon application MVC. Je n'ai pas l'intention d'avoir une authentification par jeton avec mes appels javascript api, parce que c'est dans la même application. Je peux juste utiliser [authorize] attribut sur un noeud final d'API, lorsqu'un utilisateur n'est pas connecté, il ne recevra pas les données.
De plus, lorsque vous utilisez des paniers et que vous souhaitez stocker le panier d'un utilisateur dans une session (même s'il n'est pas connecté), vous devez également l'indiquer dans votre API si vous ajoutez/supprimez des produits via votre code javascript. Cela donnera à coup sûr à votre API un état dynamique, mais réduira également la complexité de votre API MVC.
Steven de SimpleInjector (framework IoC) conseille deux projets distincts: Quelle est la différence entre DependencyResolver.SetResolver et HttpConfiguration.DependencyResolver dans WebAPI
J'ai récemment fait à peu près la même chose: j'ai commencé avec un nouveau projet d'application Web MVC 4 en choisissant le modèle d'API Web dans VS2012.
Cela créera une API Web hébergée dans la même application que MVC.
Je voulais déplacer les ApiControllers dans un projet de bibliothèque de classes séparé. C'était assez facile mais la solution était un peu cachée.
Dans AssemblyInfo.cs du projet MVC 4, ajoutez une ligne de code similaire
[Assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
Maintenant vous avez besoin de la classe LibraryRegistrator (n'hésitez pas à le nommer comme vous le voulez)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
Dans le projet MVC 4, ajoutez également une référence à la bibliothèque Api.
Vous pouvez maintenant ajouter des contrôleurs Api à votre propre bibliothèque de classes séparée (yourown.dll).
Même si votre projet est suffisamment complexe pour justifier deux "interfaces", je n’envisagerais toujours que scinder Webapi en un projet distinct en dernier recours. Vous aurez des problèmes de déploiement et il serait difficile pour un débutant de comprendre la structure de votre solution. Sans parler des problèmes de routage.
Je voudrais garder l’espace de noms system.web isolé dans la "couche de présentation". Bien que la webapi ne soit pas présentation, elle fait toujours partie de l'interface de votre application. Tant que vous gardez la logique dans votre domaine et non vos contrôleurs, vous ne devriez pas rencontrer trop de problèmes. De plus, n'oubliez pas d'utiliser les zones.
J'ai essayé de scinder les contrôleurs d'API dans un nouveau projet. Tout ce que j'ai fait est de créer un nouveau projet de bibliothèque, déplacé les contrôleurs à l'intérieur du dossier nommé API. Puis ajouté la référence du projet de bibliothèque au projet MVC.
La configuration webAPI est laissée dans le projet MVC lui-même. Ça fonctionne bien.
En plus d'installer le DLL séparé pour le Web.Api.
Juste une suggestion:
- Créer le projet
- Nugget WebActivatorEx
Créer une classe Méthode à appeler lors de app_start
[Assembly: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Démarrer")]
[Assembly: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Arrêt")]
Enregistrer un itinéraire web.api dans la méthode de démarrage
public statique void Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }
Référencez le projet au projet Web. activer la méthode de démarrage.
J'espère que cela t'aides.