Devrions-nous appeler les API Web de l'application MVC dans la même solution?

Je travaille sur un projet dans MVC qui a une application mobile. Une chose est claire: nous devons utiliser une API Web pour pouvoir l'utiliser dans une application mobile.

Après avoir créé l'API lorsque nous avons commencé à développer un site Web, nous sommes confus et avons discuté de l'opportunité d'utiliser l'API ou d'accéder directement à l'objet Business. Et nous avons fini par avoir l'avis d'un développeur plus expérimenté pour utiliser l'API Web au lieu d'utiliser directement l'objet Business.

J'ai de la confusion en ce qui concerne cette structure de solution.

1) Pourquoi devrions-nous utiliser l'API Web et faire une requête HTTP (qui prend beaucoup de temps) pour obtenir ou mettre des données à la place de l'objet métier directement dans la même solution?

2) Après avoir eu des arguments, ils ont dit ce qui se passe si le client souhaite héberger une API et le Web sur un serveur cloud différent et applique la mise à l'échelle uniquement sur l'API ou peut-être qu'il souhaite disposer d'une URL différente pour accéder aux API et au Web (ce qui est logique). Donc, dans ce cas, devrions-nous appeler l'API Web de l'application MVC dans la même solution?

3) Si nous hébergeons des API et des sites Web sur différents hébergements, cela signifie que notre site Web utilisera WebClient et utilisera un appel HTTP à chaque navigation. Est ce juste?

4) Si les objets métier sont constitués à la fois par une API et un hébergement Web sur un serveur différent, toute modification de BL nécessitera une mise à jour de la construction sur les deux serveurs.

5) Ou nous devrions créer un seul projet pour l'API et ajouter des vues ou des pages html pour développer l'interface Web afin d'appeler directement l'API depuis ajax.

Selon mes connaissances, n ° 5 est la meilleure solution ou API ne concerne que les accès tiers. Si nous avons une base de données, une couche EF, une couche de données et une couche métier dans la même solution, nous ne devrions pas utiliser d'API pour passer des appels HTTP et accéder directement à un objet métier. (corrigez-moi si je me trompe). Une API est nécessaire lorsque une application mobile, un ordinateur de bureau ou tout autre utilisateur souhaite accéder à une application afin que nous puissions avoir le même référentiel et la même couche de données.

Dans mon scénario, je dois créer une API car nous avons également une application mobile et, du côté de l'API de projet, nous avons appelé couche métier (projet séparé) et la couche métier communique avec la couche d'accès aux données (projet séparé). Ma question est donc la suivante: si nous hébergeons notre API et notre site Web sur différents serveurs, alors appeler une API qui est une requête HTTP peut prendre plus de temps que d’utiliser une méthode de la couche métier lorsque nous créons le projet et que nous avons le fichier .dll de la couche métier. Dans le contrôleur API, nous convertissons simplement la vente de notre entreprise au format JSON.

J'ai cherché sur internet mais je n'ai pas eu de réponse convaincante. J'ai trouvé un blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discutant du même point mais encore Dans ce blog, ma question est la suivante: pourquoi devons-nous envisager le scénario n ° 3?

Mise à jour: Nous pouvons avoir différents projets API et projets MVC et appeler l'API depuis le Web à l'aide de jvascript ou à l'aide du modèle MVVM.

Bonne question! Je cherche toujours un meilleur moyen de structurer mes projets. Chaque point que vous soulevez a du mérite et après avoir exploré diverses structures de solutions, je dois dire que je suis d'accord avec la majorité des commentaires ici: il n'y a pas de solution parfaite. Quelques questions à vous poser face à ce type de problème: Quelle est la complexité de cette application? Avec combien de systèmes devrai-je intégrer - ou combien de systèmes devront-ils intégrer ce système? Combien de tests ai-je prévu de faire? Existe-t-il une équipe de conception / interface distincte? Aurons-nous besoin d'évoluer? Qu'est-ce qui constitue une session?

Examinons quelques scénarios et les moyens d'utiliser une ingénierie intelligente pour rendre les choses vraiment éclatantes (et quelques astuces pour les rendre un peu plus faciles).

Hébergement de l'API et du site Web dans le même projet
Dans ce cas, vous pouvez avoir une solution unique avec zéro projet ou plus dans la couche de gestion et un seul projet hybride MVC / WebAPI (ainsi que d'autres projets - utilitaire, etc.).

Pro
Tout est en un seul endroit .. Pas besoin de corne de chaussure dans la messagerie compliquée (HttpClient appels), vous pouvez avoir l' état de session partagée (client et serveur via les cookies, InProc / OutOfProc session, etc.), la mise en commun de connexion, logique partagée, etc. Le déploiement ne pourrait être plus simple.

Con
Tout est en un seul endroit .. Ceci est probablement la structure la plus monolithique possible. Il n'y a pas d'interfaces clairement définies entre vos couches. Vous vous retrouvez avec une cohésion élevée . Les développeurs paresseux éviteront les interfaces avec ce type d'architecture, ce qui rend les tests très pénibles. Mettre à l'échelle / co-localiser l'application sera difficile.

Utilisations
J'utiliserais cette structure de projet pour une application unique, interne ou simple. Construire un système rapide pour suivre l’inscription au camp de basketball au Y local? Ceci est votre architecture!

WebAPI et site Web dans différents projets
J'ai tendance à préférer ce cas. Vous avez une solution unique avec un (ou plusieurs) projet (s) MVC et un projet WebAPI.

La
modularisation de Pro ! Couplage lâche! Chaque projet peut être autonome, testé séparément et géré différemment. Cela vous permet de mettre en œuvre plus facilement différentes stratégies de mise en cache en fonction de vos besoins. En gardant des limites solides entre vos différents systèmes, vous pouvez plus facilement établir des contrats vous permettant d'appliquer des modèles d'utilisation spécifiques et de réduire les frictions éventuelles (lisez: moins de bogues avec moins de possibilités d'abuser de l'API). La mise à l'échelle est un peu plus facile car il vous suffit de mettre à l'échelle les bits qui voient une charge élevée. L'intégration devient également un peu plus facile à gérer car vous devrez avoir une idée de ce à quoi votre API ressemblera dès le début.

La
maintenance de Con est un peu plus difficile. Des moyens multiples projets dont vous aurez besoin propriétaires de projet / fonction pour garder une trace des fusions, des contrats (interfaces), déploiements, etc. entretien Code, la dette technique , suivi des erreurs, la gestion de l' Etat - tous deviennent des préoccupations qu'ils pourraient avoir besoin d'être mis en œuvre différemment selon sur vos besoins. Ces types d’applications exigent également le plus de planification et de conservation au fur et à mesure de leur croissance.

Utilisations
Construire une application qui pourrait avoir 100 utilisateurs aujourd'hui et 100 000 la semaine / mois? L'application doit-elle envoyer des notifications, gérer des flux de travail complexes et disposer de plusieurs interfaces (Web + application mobile + SharePoint)? Vous avez beaucoup de temps libre et vous adorez résoudre plus de 5000 énigmes au cours du week-end? C'est l'architecture pour vous!

Conseils
Après avoir exposé ce qui précède, je peux comprendre à quoi votre prochain projet pourrait sembler un peu intimidant. Pas de soucis, voici quelques astuces que j'ai apprises au fil des ans.

1. Essayez d'utiliser des sessions sans état. Sur des systèmes plus petits, cela peut impliquer de stocker un cookie crypté contenant au moins l'identifiant interne de l'utilisateur actuel et un délai d'attente. Les systèmes plus grands peuvent vouloir dire stocker un cookie crypté avec un identifiant de session simple pouvant être récupéré depuis une banque de données (redis, table de stockage, DHT , etc.). Si vous pouvez stocker suffisamment d'informations pour ne pas avoir à accéder à la base de données principale à chaque demande, vous serez bien placé - mais essayez de garder les cookies sous 1k.
2. Sachez qu'il y aura probablement plus d'un modèle. Essayez de penser en termes de modèles et de projections (les liens que j'ai trouvés ici étaient .. pas bons .. pensez: un élément d'inventaire d'un homme correspond à la ligne de commande d'un autre - même structure de base sous-jacente, mais points de vue différents). Certains projets ont un modèle différent pour chaque limite logique / conceptuelle (c.-à-d. En utilisant un modèle spécifique pour la communication avec une API spécifique.
3. L'API est partout! À chaque fois qu'un objet / une classe / une structure expose des données ou un comportement, vous établissez une API. Soyez conscient de la manière dont d'autres entités ou dépendances utiliseront cette API. Réfléchissez à la façon dont vous pourriez tester cette API. Considérez ce qui pourrait parler à cette API (autres objets via le code? D'autres systèmes via un protocole?) Et comment ces données sont exposées (fortement typé? JSON? * Cough * XML?).
4. Construisez pour ce que vous avez, pas ce que vous imaginez avoir dans deux ans. Une autre réponse fait référence à YAGNI - ils ont tout à fait raison! La résolution de problèmes imaginaires rend votre échéance imaginaire. Fixez-vous des objectifs concrets et atteignez-les. Déployer! Un projet en développement est un projet avec un seul utilisateur - vous!
5. YMMV (votre kilométrage peut varier). Il n'y a qu'un seul absolu ici: il y a un problème, vous construisez une solution. Tout le reste est complètement en l'air. Les deux solutions ci-dessus peuvent être un succès fou - et un échec de succion. Tout dépend de vous, de vos outils et de la manière dont vous les utilisez. Marchez doucement, développeur!

Accéder directement à vos objets métier directement (je suppose que vous voulez dire dans votre contrôleur) sera plus rapide et plus facile.

que se passe-t-il si le client souhaite héberger l'API et le Web sur un serveur cloud différent et applique la mise à l'échelle uniquement sur l'API ou peut-être souhaite-t-il disposer d'URL différentes pour accéder à l'API et au Web (ce qui est un peu logique)?

Ensuite, vous devrez les héberger séparément ... mais cela ne me semble pas très logique, vous voudriez sûrement faire évoluer les deux. Êtes-vous sûr de devoir répondre à cette exigence? Cela ressemble à de l'overkill. Rappelez-vous YAGNI - si vous n'en avez pas besoin, ne le construisez pas. Lorsque vous en avez besoin, construisez-le.

Si c’était moi, je construirais le site en utilisant la technologie qui convient le mieux au site, puis, si (si) vous avez besoin d’un service que d’autres personnes peuvent appeler, construisez-le séparément.

Je dirais; préférez appeler MVAP WebAPI via HTTPClient. La logique du noyau de la DLL est écrasante, mais l’avantage principal est que votre système global aura un accès unique aux objets du domaine sur HTTP ... Quoi qu’il en soit ... avec la prise en charge de Micro Service Architecture ET les applications qui basculent déjà vers Frameworks côté client (AngularJS, etc.) ... il est préférable de traiter MVC comme un autre client ... et de permettre à votre équipe de bien gérer les API ...

GARDEZ-LE SIMPE. J'espère que cette aide. Merci..