Faut-il appeler l'API Web depuis l'application MVC dans la même solution?
Je travaille sur un projet dans MVC qui a une application mobile, donc une chose est claire: nous devons utiliser l'API Web pour qu'elle puisse être utilisée 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'utilisation de l'API ou de l'accès direct à l'objet métier. Et nous nous sommes retrouvés après avoir exprimé l'opinion d'un développeur plus expérimenté pour consommer l'API Web au lieu d'utiliser directement l'objet métier.
J'ai de la confusion concernant cette structure de solution.
1) Pourquoi nous devrions utiliser l'API Web et faire une requête HTTP (ce qui prend du temps) pour obtenir ou mettre directement des données au lieu d'un objet métier qui est dans la même solution.
2) Après avoir eu des arguments, ils ont dit que si le client voulait héberger l'API et le Web sur un serveur cloud différent et appliquer une mise à l'échelle uniquement sur l'API ou qu'il souhaitait avoir une URL différente pour accéder à l'API et au Web (ce qui est logique). Dans ce cas, devrions-nous appeler l'API Web à partir de l'application MVC dans la même solution?
3) Si nous hébergeons l'API et le Web sur un hébergement différent, cela signifie que notre Web utilisera WebClient et aura un appel HTTP sur chaque navigation. Est ce juste?
4) Si nous allons créer un objet métier à la fois API et hébergement Web sur un serveur différent, si quelque chose change dans BL, il faudra mettre à jour la version sur les deux serveurs.
5) Ou nous ne devons créer qu'un seul projet pour l'API et pouvons ajouter des vues ou des pages html pour développer une interface Web afin de pouvoir ainsi appeler directement l'API depuis ajax.
Selon ma connaissance, le n ° 5 est la meilleure solution ou l'API est réservée à un accès tiers. Si nous avons DB, EF, couche de données et couche métier dans la même solution, nous ne devons pas utiliser l'API pour effectuer des appels HTTP et accéder directement à l'objet métier. (corrigez-moi si je me trompe) L'API est nécessaire lorsqu'une application mobile ou un ordinateur de bureau ou quelqu'un souhaite accéder à l'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é la couche métier (projet séparé) et la couche métier communiquer avec la couche d'accès aux données (projet séparé). Donc, ma question est de savoir si nous hébergeons notre API et notre site Web sur différents serveurs, puis appeler l'API, qui est une demande HTTP, peut prendre plus de temps que d'utiliser la méthode de la couche métier lorsque nous créons le projet et que nous avons .dll de la couche métier. Dans le contrôleur API, nous convertissons simplement nos produits au format json.
J'ai cherché sur Internet mais je n'ai pas obtenu 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 une fois dans ce blog, ma question est pourquoi nous devons considérer le scénario # 3?
Mise à jour: Nous pouvons avoir différents projets d'API et projets MVC et nous pouvons appeler l'API à partir du Web à l'aide de jvascript ou utiliser le modèle MVVM.
Grande question! Je cherche toujours une meilleure façon de structurer mes projets. Chaque point que vous soulevez a du mérite et après avoir exploré une variété de structures de solution, 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 dois-je intégrer - ou combien de systèmes devront intégrer avec ce système? Combien de tests dois-je faire? Existe-t-il une équipe de conception/interface utilisateur distincte? Devrons-nous évoluer? Qu'est-ce qui constitue une session?
Examinons quelques scénarios et façons d'utiliser un peu d'ingénierie intelligente pour faire vraiment bouger les choses (et quelques astuces pour rendre les choses 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 seule solution avec zéro ou plusieurs projets de couche métier et un seul projet hybride MVC/WebAPI (ainsi que d'autres projets - utilitaire, etc.).
Pro
. logique partagée, etc. Le déploiement ne pourrait pas être plus simple.
Con
Tout est au même endroit. C'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 haute cohésion . Les développeurs paresseux éviteront les interfaces lorsqu'ils traitent avec ce type d'architecture, ce qui rend les tests très difficiles. La mise à l'échelle/colocalisation de l'application sera difficile.
Utilise
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 basket-ball 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.
Pro
Modularisation!Loose Coupling! Chaque projet peut être autonome, être 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 frontières solides entre vos différents systèmes, vous pouvez plus facilement établir des contrats qui vous permettent d'appliquer des modèles d'utilisation spécifiques et de réduire les frictions possibles (lire: moins de bogues avec moins de possibilité 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 subissent une charge élevée. L'intégration devient également un peu plus facile à gérer, car vous devrez avoir une idée de l'apparence de votre API dès le départ.
Con
La maintenance est un peu plus difficile. Plusieurs projets signifient que vous aurez besoin de propriétaires de projets/fonctionnalités pour suivre les fusions, les contrats (interfaces), les déploiements, etc. Entretien du code, dette technique , suivi des erreurs, gestion des états - tous deviennent des préoccupations car ils peut avoir besoin d'être implémenté différemment selon vos besoins. Ces types d'applications nécessitent également le plus de planification et de conservation au fur et à mesure de leur croissance.
Utilise
Vous construisez une application qui pourrait avoir 100 utilisateurs aujourd'hui et 100 000 la semaine/le mois prochain? L'application doit-elle envoyer des notifications, gérer des workflows complexes et avoir plusieurs interfaces (web + application mobile + SharePoint)? Vous avez beaucoup de temps libre et vous adorez résoudre des puzzles de plus de 5000 pièces au cours du week-end? Voici l'architecture pour vous!
Conseils
Ayant décrit ce qui précède, je peux comprendre à quoi pourrait ressembler votre prochain projet. Pas de soucis, voici quelques trucs que j'ai appris au fil des ans ..
- Essayez d'utiliser des sessions sans état. Sur les petits systèmes, cela peut signifier le stockage d'un cookie chiffré contenant au moins l'ID interne de l'utilisateur actuel et un délai d'expiration. Des systèmes plus importants peuvent signifier le stockage d'un cookie chiffré avec un identifiant de session simple qui peut être récupéré dans une banque de données (redis, stockage de table, DHT , etc) .. Si vous pouvez stocker suffisamment d'informations pour que vous ne le faites pas devez accéder à la base de données principale à chaque demande, vous serez alors dans une bonne position - mais essayez de garder les cookies sous 1k.
- 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: l'élément d'inventaire d'un homme est l'élément de ligne de commande d'un autre homme - même structure sous-jacente de base, mais vues différentes). Certains projets ont un modèle différent pour chaque frontière logique/conceptuelle (c'est-à-dire en utilisant un modèle spécifique pour la communication avec une API spécifique.
- Les API sont partout! Chaque fois qu'un objet/classe/structure expose des données ou un comportement, vous établissez une API. Soyez conscient de la façon 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 (d'autres objets via du code? D'autres systèmes via un protocole?) Et comment ces données sont exposées (fortement typées? JSON? * Cough * XML?).
- Construisez pour ce que vous avez, pas pour ce que vous imaginez avoir dans deux ans. Une autre réponse fait référence YAGNI - ils sont absolument corrects! La résolution de problèmes imaginaires rend votre échéance imaginaire. Fixez des objectifs solides pour vos itérations et atteignez-les. Déployer! Un projet en développement est un projet avec un seul utilisateur - vous!
- YMMV (Votre kilométrage peut varier). Il n'y a qu'un 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 façon dont vous les utilisez. Marchez légèrement, collègue 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 appliquer une mise à l'échelle uniquement sur l'API ou qu'il souhaite avoir une URL différente pour accéder à l'API et au Web (ce qui est quelque peu logique)
Ensuite, vous devrez les héberger séparément ... mais cela ne me semble pas très logique, vous voudrez sûrement mettre à l'échelle les deux. Voulez-vous vraiment répondre à cette exigence? Cela semble exagéré. N'oubliez pas 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, alors quand (si) vous avez besoin d'un service que d'autres personnes peuvent appeler, construisez-le séparément.
Je dirais; préférez que MVC appelle WebAPI via HTTPClient. Il est écrasant de contourner la logique des "dll de base", mais le principal avantage est que votre système global aura un accès unique aux objets de domaine sur HTTP ... Quoi qu'il en soit, avec la prise en charge de Micro Service Architecture ET des applications qui passent déjà à Cadres côté client (AngularJS, etc.) .... mieux vaut traiter MVC comme un autre client ... et former votre équipe pour bien gérer les API ...
GARDEZ-LE SIMPE. J'espère que cette aide. Merci..