J'ai eu une discussion animée aujourd'hui au sujet de notre application MVC. Nous avons un site Web écrit en MVC ( ASP.NET ), et il suit généralement le modèle de faire quelque chose dans la vue -> appuyer sur le contrôleur -> le contrôleur construit un modèle (appelle un gestionnaire qui récupère les données, construit le modèle dans le méthode du contrôleur lui-même) -> modèle va voir -> rinçage et répéter.
Il a dit que notre code était trop étroitement lié. Par exemple, si nous voulions également une application de bureau, nous ne pourrions pas utiliser notre code existant.
La solution et la meilleure pratique, a-t-il déclaré, consiste à créer une API, puis à créer votre site Web au-dessus de votre API, puis à créer une application de bureau, une application mobile, etc. est très simple.
Cela me semble une mauvaise idée pour diverses raisons.
Quoi qu'il en soit, je ne trouve pas quoi que ce soit en googlant qui puisse discuter de cette pratique. Quelqu'un at-il des informations sur les avantages, les inconvénients, pourquoi vous devriez, pourquoi vous ne devriez pas ou une lecture plus approfondie?
Quelques raisons pour lesquelles je pense que c'est une mauvaise idée:
C'est beaucoup trop abstrait pour exécuter votre back-end d'une API. Vous essayez de le rendre trop flexible, ce qui en fera un gâchis ingérable.
Tout ce qui est construit dans MVC semble inutile, comme les rôles et l’authentification. Par exemple, les attributs [Autoriser] et la sécurité; vous devrez rouler le vôtre.
Tous vos appels d'API nécessiteront des informations de sécurité en pièce jointe, et vous devrez développer un système de jetons et ainsi de suite.
Vous devrez écrire des appels d'API complets pour chaque fonction que votre programme accomplira. Pratiquement toutes les méthodes que vous souhaitez implémenter devront être exécutées à partir d'une API. A Obtenir / Mettre à jour / Supprimer pour chaque utilisateur, plus une variante pour chaque autre opération, par exemple, mettre à jour le nom d'utilisateur, ajouter un utilisateur à un groupe, etc., etc., chacune d'elles constituant un appel d'API distinct.
Vous perdez toutes sortes d'outils comme les interfaces et les classes abstraites en matière d'API. Des choses comme WCF ont un support très ténu pour les interfaces.
Vous avez une méthode qui crée un utilisateur ou effectue une tâche. Si vous voulez créer 50 utilisateurs, vous pouvez l'appeler 50 fois. Lorsque vous décidez de faire cette méthode en tant qu'API, votre serveur Web local peut nommer des canaux nommés et aucun problème - votre client de bureau peut également y accéder, mais soudainement, la création en bloc d'un utilisateur impliquera de marteler l'API sur Internet 50 fois, ce qui n'est pas le cas. pas bien. Vous devez donc créer une méthode en bloc, mais vous ne la créez que pour les clients de bureau. De cette façon, vous finissez par devoir a) modifier votre API en fonction de son intégration, et vous ne pouvez pas simplement y intégrer directement, b) faire beaucoup plus de travail pour créer une fonction supplémentaire.
YAGNI . Sauf si vous envisagez spécifiquement d'écrire deux applications fonctionnant de manière identique, une application Web et une application Windows, par exemple, cela représente une énorme quantité de travail de développement supplémentaire.
Le débogage est beaucoup plus difficile lorsque vous ne pouvez pas parcourir de bout en bout.
De nombreuses opérations indépendantes nécessitant beaucoup de va-et-vient, par exemple, du code peut obtenir l'utilisateur actuel, vérifier que l'utilisateur est dans le rôle d'administrateur, obtenir la société à laquelle l'utilisateur appartient, obtenir la liste des autres membres, les envoyer à tous un courriel. Cela nécessiterait de nombreux appels d'API ou l'écriture d'une méthode sur mesure de la tâche spécifique que vous souhaitez, où le seul avantage de cette méthode sur mesure serait la rapidité, mais l'inconvénient serait qu'elle serait inflexible.
Probablement quelques autres raisons qui me viennent à l’esprit.
Il me semble que, sauf si vous avez vraiment besoin de deux applications identiques, cela ne vaut vraiment pas la peine. Je n'ai jamais vu une application ASP.NET construite comme celle-ci non plus, vous auriez à écrire deux applications distinctes (l'API et votre code) et à les contrôler toutes les deux aussi (si votre page utilisateur reçoit un nouveau champ, vous ' Il est nécessaire de mettre à jour l’API et votre code utilisateur simultanément pour éviter tout effet indésirable ou pour déployer beaucoup de travail supplémentaire afin de le maintenir robuste).
Edit: Quelques bonnes réponses, commencent vraiment à avoir une bonne idée de ce que tout cela signifie maintenant. Donc, pour développer ma question, comment structureriez-vous une application MVC pour qu'elle suive cette structure d'API?
Par exemple, vous avez un site Web qui affiche des informations sur un utilisateur. Sous MVC, vous avez:
View - Page HTML (CS) qui affiche un contrôleur UserViewModel - Appelle GetUser () et crée un UserViewModel qu'il transmet à la classe View Manager (sorte de votre API) comportant une méthode GetUser.
Le contrôleur effectue GetUser () mais vous souhaitez également une application de bureau. Cela signifie que votre GetUser doit être exposé via une sorte d'API. Vous voudrez peut-être une connexion TCP, WCF, ou peut-être Remoting. Vous voulez également une application mobile qui sera RESTful puisque les connexions persistantes sont irrégulières.
Alors, écririez-vous ensuite une API pour chaque service, un service Web WCF qui possède une méthode GetUser () et le code le fait return new UserManager().GetUser()
? Et une méthode mvc 4 web api qui fait la même chose? Tout en continuant à appeler GetUser directement dans votre méthode de contrôleur MVC?
Ou choisiriez-vous la solution qui fonctionnerait pour les trois services Web (service REST Web Api) et construiriez-vous le dessus?
Et s’agit-il d’un scénario théorique parfait? Je peux voir de gros frais généraux dans le développement de cette façon, surtout si vous devez développer de manière à vous permettre de faire des opérations de manière RESTful. Je pense qu'une partie de cela a été couverte dans les réponses.
Edit 2: Après avoir lu plus de choses, j'ai mis un commentaire ci-dessous que je pense pourrait l'expliquer. La question est un peu une question piège, je pense. Si vous écrivez votre back-end en tant qu'API, j'ai eu du mal à croire qu'il devrait exister un seul service Web qui appelle tout (applications mvc, applications de bureau, applications mobiles).
La conclusion à laquelle je suis arrivé est que vous devez réellement vous assurer que votre couche de logique métier est correctement découplée. En regardant mon code, je le fais déjà: le contrôleur fera appel GetUser()
à un gestionnaire, puis en créera un modèle de vue à restituer avec une vue. Alors vraiment, la couche de logique métier est une API. Si vous souhaitez l'appeler depuis une application de bureau, vous devez écrire quelque chose comme un service WCF pour faciliter l'appel. Le simple fait d'avoir une méthode WCF appelée GetUser()
contenant le code return MyBusinessLayer.GetUser()
serait suffisant. Donc, l'API est la logique métier, et WCF / web api, etc. ne sont que des fragments de code permettant aux applications externes de l'appeler.
Il y a donc un surcoût, dans la mesure où vous devez encapsuler votre couche de logique métier dans différentes API en fonction de vos besoins, et vous devez écrire une méthode API pour chaque opération que vous souhaitez exécuter avec vos autres applications. trier un moyen de faire l'authentification, mais pour la plupart c'est la même chose. Collez votre logique métier dans un projet séparé (bibliothèque de classes) et vous n'aurez probablement aucun problème!
Espérons que cette interprétation est correcte. Merci pour toutes les discussions / commentaires qu'il a générés.