API Web dans une solution MVC dans un projet séparé

Question

Je suis en train de créer un nouveau projet MVC4 et j'ai récemment lu cet article concernant l'API web : http://encosia.com/asp-net-web-api-vs-asp-net-mvc-apis/

Cela m'a conduit à faire des recherches plus approfondies et j'ai découvert que la communication entre le javascript et le côté serveur est mieux réalisée maintenant par le biais de l'API web que par les actions du contrôleur. Est-ce que je comprends bien ?

Je présume que je peux partager tous mes attributs, etc., entre l'API Web et les contrôleurs MVC ; à première vue, cela ne me semble pas être un changement radical.

Lorsque je configure des applications, j'aime diviser les composants en plusieurs projets. Mon plan était d'avoir un projet MVC et un projet API web. Mais je me suis heurté à des problèmes. Par exemple, je me suis retrouvé avec deux applications en tant que telles, avec des routages distincts, etc.

Ma question est donc la suivante : dans une application MVC, le cadre de l'API Web doit-il être intégré au même projet ou doit-il être séparé dans un projet distinct pour contourner les problèmes ?

Answer 1

Malheureusement, vous avez tort à ce sujet - Je présume que je peux partager tous mes attributs, etc., entre l'API Web et les contrôleurs MVC, ce qui, à première vue, ne me semble pas être un changement radical.

De nombreux concepts utilisés par l'API Web et MVC, même s'ils sont similaires à première vue, ne sont en fait 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 - model binding (mécanismes complètement différents), routes (l'API Web utilise HTTPRoutes et non Routes, même s'ils fonctionnent tous deux sur la même RouteTable), résolveur de dépendances (non compatible) et bien d'autres - qui, bien que similaires en apparence, sont très différents en pratique. De plus, l'API Web ne possède pas de concept de zones.

En fin de compte, si tout ce que vous essayez de faire est d'avoir une façon "nouvelle et branchée" de servir du contenu JSON, réfléchissez-y à deux fois avant de vous engager dans cette voie. Je ne recommanderais certainement pas de remanier le code existant, à moins que vous ne souhaitiez vraiment adopter le protocole HTTP et construire votre application de manière RESTful.

Tout dépend vraiment de ce que vous construisez. Si vous démarrez un nouveau projet, et que tout ce dont vous avez besoin est de servir du JSON pour faciliter votre application Web - à condition que vous soyez prêt à vivre avec du code potentiellement dupliqué (comme ce que j'ai mentionné ci-dessus), l'API Web peut facilement être hébergée dans le même projet que ASP.NET MVC.

Je ne séparerais l'API Web en un projet distinct que si vous comptez construire une véritable API pour votre service en ligne - peut-être pour qu'il soit consommé par des clients externes, ou par divers appareils - comme pour alimenter vos applications mobiles.

Answer 2

IMO, la sécurité et le déploiement doivent guider votre décision. Par exemple, si votre application MVC utilise l'authentification Forms mais que vous souhaitez utiliser l'authentification Basic (avec SSL) pour votre API, des projets distincts vont vous faciliter la vie. Si vous souhaitez héberger votre site à l'adresse www.example.com mais héberger votre API sous api.example.com (au lieu de www.example.com/api), des projets distincts vous faciliteront la vie. Si vous séparez vos projets et les sous-domaine en conséquence et que vous avez l'intention de tirer parti de votre propre API à partir de votre application MVC, vous devrez trouver un moyen de gérer l'élément Politique de l'origine identique pour les appels côté client à votre API. Les solutions courantes consistent à utiliser jsonp o 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

Answer 3

Steven de SimpleInjector (framework IoC) conseille deux projets séparés : Quelle est la différence entre DependencyResolver.SetResolver et HttpConfiguration.DependecyResolver dans la WebAPI ?

Answer 4

J'ai récemment fait presque la même chose : j'ai commencé avec un nouveau projet d'application Web MVC 4 en choisissant le modèle API Web dans VS2012.

Cela permettra de créer 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 la ligne de code suivante

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

Maintenant, vous avez besoin de la classe LibraryRegistrator (n'hésitez pas à la nommer comme vous 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 les contrôleurs Api à votre propre bibliothèque de classes séparée (yourown.dll).

Answer 5

Même si votre projet est si complexe qu'il justifie deux "front ends", je n'envisagerais la séparation de webapi dans un projet séparé qu'en dernier recours. Vous aurez des problèmes de déploiement et il sera difficile pour un débutant de comprendre la structure de votre solution. Sans parler des problèmes de routage.

J'aimerais que l'espace de nom system.web soit isolé dans la seule "couche de présentation". Bien que le webapi ne soit pas présentation il fait toujours partie de l'interface de votre application. Tant que vous conservez la logique dans votre domaine et non dans vos contrôleurs, vous ne devriez pas rencontrer trop de problèmes. N'oubliez pas non plus d'utiliser les domaines.