Comment combiner l'Api Web et MVC meilleur dans une seule application web
Je suis sur le point de créer une simple application web et je me demandais si je devrais utiliser ASP.NET MVC 4 nouvelle fonctionnalité Web API.
Quelle est la meilleure façon de le faire ?
J'ai fait quelques recherches et j'ai découvert il y a deux option :
Option 1
Rendre le Web Api de ma couche de service et l'appeler à partir du contrôleur de lire/écrire des données, et de rendre la vue à l'aide de modèles de vue et rasoir.
Option 2
Rendre le Web Api de ma couche de service et appeler directement à partir de la vue à l'aide de Javascript.
Je ne suis pas un grand fan de Option 2 depuis que j'ai l'impression que je suis en négligeant le contrôleur qui sera utilisé uniquement pour la redirection entre les pages. D'ailleurs, je préfère utiliser de rasoir plutôt que de Javascript.
Et Si je choisis Option 1 vais-je devoir faire une instance de l'une API Web dans le contrôleur? parce que cela se sent comme je suis en train de faire quelque chose de mal.
Quelle est la meilleure option ? Est-il d'autres options que je n'ai pas pris en compte ?
Et si vous pouvez donner des références ou des livres qui peuvent m'aider, j'apprécierais.
Grâce.
- Je choisirais l'option la plus simple, avec l'option 2 semble être la plus simple des deux options présentées.
Vous devez vous connecter pour publier un commentaire.
D'habitude, j'ai une autre couche (qui peut être un autre projet ou de l'assemblage en fonction de la taille et de la complexité de votre application) pour mon règles métier. Vous pouvez appeler cette services aux entreprises, ou tout ce qui fonctionne dans votre cas.
De sorte que les deux contrôleurs MVC et contrôleurs d'API utilisation de cette couche; qui maintient l'application sèche.
Personnellement, je préfère ne garder que les opérations complexes dans mon entreprise, les couches, ce qui signifie que si j'ai besoin de lire quelque chose de ma couche de persistance de l'affichage de mon point de vue, je le fais directement sur le contrôleur MVC. C'est une question de préférence personnelle, mais je préfère aller à la CQRS façon.
De sorte que vous contrôleurs MVC allons instancier ces services aux entreprises (ou ils seront injectés dans vos contrôleurs si vous utilisez Cio). Pour les opérations de lecture vous pouvez choisir d'aller directement à votre persistance de la couche ou d'utiliser une autre lecture de la stratégie.
La même chose se produira pour vos contrôleurs d'API, ils vont utiliser cette "commune" de la couche de services.
Vous n'avez pas besoin d'instancier votre API Contrôleurs Contrôleurs MVC.
Consommer votre contrôleurs d'Api Web via AJAX est ok si vous êtes l'élaboration d'un SPA ou similaire.
Il n'y a pas qu'une seule manière de la structure de votre application, il y a juste des façons différentes et chacune a plus ou moins de douleur attaché.
Si vous êtes envisage d'introduire des tests dans vos applications (et vous devriez :)); ensuite, vous devez mettre en place une structure, il est facile de tester chaque partie.
Juste mes 2 cents.
Le point de l'ensemble de l'API Web est d'être un apatride service RESTful. Il n'y aurait jamais être une instance de celui-ci si vous le faites à droite. Je me rends compte que cette question est ancienne et vous pouvez personnellement appris cela, mais la réponse n'est pas tant pour vous que c'est une réponse à l'un des plus fréquemment posées question.
Noter que lorsque l'on parle de Web API, le plus souvent, les gens parlent de ApiControllers et pas de base MVC "Contrôleurs" que prendre des routes et de les transformer en points de Vue.
Donc, dans votre projet, vous pouvez avoir des "Contrôleurs", qui n'certaines de vue de base de la logique, mais pas de la logique métier. Ne pas confondre avec le reste de votre Couche de Service qui est un wrapper pour votre Entreprise, la Logique et la Persistance d'accès.
Moi, et beaucoup d', je suis d'avis que ApiControllers ne doit pas être mélangé avec votre application MVC. Gardez à l'esprit que MVC ne se mélangent pas bien avec de l'API Web. Comme Filip W dit:
Plus souple réponse
Donc, ce que vous avez à faire est de créer un sous-domaine nommé api.YourWebsite.com et construire une nouvelle API Web ApiController projet. Que le Projet de API Web doit RIEN faire de plus que d'instancier et d'exposer une Logique d'Entreprise via ApiControllers et l'Injection de Dépendance.
Alternative 1
Architecture Orientée Service est tout au sujet de la possibilité de réutilisation. Si vous souhaitez conserver vos applications à SEC, vous devriez certainement tomber dans SOA. Cependant, chaque situation est différente. Si vous n'utilisez jamais la même logique commerciale de ce site dans une autre application (desktop, android, tablette, ewPhones, etc), alors vous avez une autre méthode.
Créer votre Busines Couche de Logique métier comme un autre Projet, et d'y accéder directement à partir de votre application web. Lorsque votre Javascript (Angular/Rasoir?) Les contrôleurs de faire un appel, elle peut faire appel dans votre Viewmodel et/ou le Code-behind ou quelque chose de similaire, qui peut instancier une Logique d'Entreprise et d'accéder directement à elle. Pas besoin de services si tout est là, et ne sera pas réutilisé.
La variante 2
Aller de l'avant et de mettre votre Web API ApiControllers dans le même projet. Mais, assurez-vous de les séparer en plusieurs dossiers à partir de votre MVC "Contrôleurs." Pourtant, lorsque l'option Javascript de votre Contrôleurs de faire un appel, il va faire le Routage des appels vers votre site web pour les apatrides retourne. Ne pas mélanger les apatrides ApiControllers avec votre Viewmodel et d'autres MVC code.
L'inconvénient à cela est un manque de SOC. Maintenant vous avez le Service de la Couche de l'INTERFACE et de la Couche mixte, et l'INTERFACE de la Couche est forcé d'accéder à votre Couche de Logique Métier (DLL). Où est le mal si la Variante 1 a fait ça?
Bien, ce qui est faux est que la Variante 1 est une petite application avec pas de place pour la croissance. Rien d'autre (à L'origine, ou la Variante 2 ici) doit avoir de l'INTERFACE utilisateur, qui n'ont aucune idée que ce soit que la Logique Métier (ou la Persistance) existent encore. Ils devraient aller sur leur doodies à l'improviste du backend monde.