Comment gérer le débat technique entre WCF et API Web?
Je gère maintenant une équipe de 15 développeurs, et nous sommes bloqués à un moment sur le choix de la technologie, où l'équipe est divisée en deux équipes complètement opposées, discutant de l'utilisation de WCF par rapport à l'API Web.
L'équipe A, qui prend en charge l'utilisation de l'API Web, avance les raisons suivantes:
- L'API Web n'est que la manière moderne d'écrire des services ( Wikipedia )
- WCF est une surcharge pour HTTP. C'est une solution pour TCP, Net Pipes et autres protocoles
- Les modèles WCF ne sont pas POCO, en raison de [DataContract] & [DataMember] et de ces attributs
- SOAP n'est pas aussi lisible et pratique que JSON
- SOAP est une surcharge pour le réseau par rapport à JSON (transport via HTTP)
- Pas de surcharge de méthode
L'équipe B qui prend en charge l'utilisation de WCF, déclare:
- WCF prend en charge plusieurs protocoles (via la configuration)
- WCF prend en charge les transactions distribuées
- Il existe de nombreux bons exemples et exemples de réussite pour WCF (alors que l'API Web est encore jeune)
- Le duplex est excellent pour la communication bidirectionnelle
Ce débat se poursuit et je ne sais pas quoi faire maintenant. Personnellement, je pense que nous devrions utiliser un outil uniquement pour son bon endroit d'utilisation . En d'autres termes, nous ferions mieux d'utiliser l'API Web, si nous voulons exposer un service sur HTTP, mais utiliser WCF en ce qui concerne TCP et Duplex.
En cherchant sur Internet, nous ne pouvons pas arriver à un résultat solide. De nombreux messages existent pour soutenir la WCF, mais au contraire, nous trouvons également des gens qui s'en plaignent. Je sais que la nature de cette question peut sembler discutable, mais nous avons besoin de bons conseils pour décider. Nous sommes coincés à un point où le choix d'une technologie par hasard pourrait nous faire regretter plus tard. Nous voulons choisir les yeux ouverts.
Notre utilisation serait principalement pour le Web, et nous exposerions nos services sur HTTP. Dans certains cas (disons 5 à 10%), nous pourrions avoir besoin de transactions distribuées.
Qu'est-ce que je devrais faire maintenant? Comment gérer ce débat de manière constructive?
Lorsque les deux parties ont de bons arguments et que les opinions sur la question sont trop fortes pour parvenir à un consensus, vous, en tant que manager, devez prendre une décision et mettre fin au débat. Sinon, cela tournera en rond et renforcera encore plus les positions de tous les participants. Plus vous attendez, plus il sera difficile pour le côté "perdant" d'admettre la défaite et de travailler de manière productive avec le résultat.
Notez tous les arguments, évaluez leur importance pour le projet, puis prenez votre décision. Lorsque vous ne pouvez pas, lancez une pièce. Votre projet peut probablement être mené à bien avec l'une ou l'autre technologie, et perdre un temps précieux avec des débats inutiles coûtera simplement de l'argent inutile.
En supposant que les deux parties sont correctes à 100% dans tous leurs arguments, lesquels sont importants?
Les modèles WCF ne sont pas POCO, en raison de [DataContract] & [DataMember] et de ces attributs
Ça t'intéresse? Envisagez-vous de faire quelque chose qui nécessite POCO?
WCF prend en charge les transactions distribuées
Encore une fois, est-ce quelque chose que vous allez utiliser et que vous devez construire si vous ne l'avez pas parce que vous avez pris l'autre chemin?
Aller au cœur de laquelle:
- Offre tout ce dont vous avez besoin (si aucun n'offre tout ce dont vous avez besoin, ce qui vous oblige à faire le moins de travail).
- Offre le moins de déchets que vous n'allez pas utiliser, mais que vous devez malgré tout supporter.
Tout argument avancé qui n'est pas sur le chemin de ce que vous devez accomplir n'est pas pertinent et ne devrait pas prendre en compte votre décision, avec une certaine marge de manœuvre pour envisager une expansion future.
Mettez mes deux sous.
En tant que manager, vous devez demander à vos coéquipiers de garder à l'esprit le principe Yagni . Cela contribuera à réduire la liste des raisons avancées par les deux équipes.
Notre utilisation serait principalement pour le Web, et nous exposerions nos services sur HTTP. Dans certains cas (disons 5 à 10%), nous pourrions avoir besoin de transactions distribuées.
Plutôt que de plonger dans la transaction distribuée, vous devriez plutôt envisager de travailler avec compensation .
La dernière chose à prendre en compte est la courbe d'apprentissage. Selon la date limite de votre projet, en tant que gestionnaire, vous devriez être en mesure de décider si vous pouvez commencer à apprendre une nouvelle technologie ou non.
Si vous avez beaucoup de temps à perdre, optez pour une sorte de Journée de l'innovation où les équipes A et B auraient une journée pour produire des preuves de concepts basées sur les mêmes exigences.
Par ailleurs, au gars qui dit " les modèles WCF ne sont pas POCO, à cause de [DataContract] & [DataMember] et de ces attributs ", dites-lui que les POCO sont généralement destinés à être des entités de domaine et que ce n'est pas une bonne pratique d'exposer votre objet de domaine à tout type de clients, c'est à cela que servent les DTO.
Qu'est-ce que je devrais faire maintenant? Comment gérer ce débat de manière constructive?
Tout d'abord, éloignez la subjectivité. Dans les arguments de votre équipe WebAPI, je trouve "l'API Web n'est que la voie moderne" *, "Les modèles WCF ne sont pas POCO, à cause de ces attributs" et "SOAP n'est pas aussi lisible et pratique que JSON" assez perspicace, sinon tout à fait faux, et n'aidera pas à prendre une décision.
Alors, que faire: décidez ce que vous voulez faire de vos services , puis choisissez une technique qui répond à cet objectif ainsi que sa maintenabilité et son extensibilité avec le moins de douleur possible. Vous pouvez le faire en recherchant simplement si un aspect donné est pris en charge par le cadre à utiliser.
Matériel de lecture intéressant:
*: notez que vous vous référez à Wikipedia pour cela, où la citation est: " Les applications Web Web 2.0 se sont déplacées loin d'un service orienté architecture (SOA) avec des services Web basés sur SOAP vers des collections plus cohérentes de ressources Web RESTful ". C'est un exemple d'utilisation lorsque votre service doit être consommé à partir d'une page Web. Cela peut également être fait facilement avec WCF, en utilisant WebHttpBinding. Il ne dit pas "Utilisez WebAPI pour cela".
Si cette question s'étend au-delà du "comment gérer la discussion": J'utiliserais WCF si les services doivent être consommés par des non-clients Web, parce que ses métadonnées permettent une facilité étonnamment facile fortement- génération de client typé.
Notre équipe a eu une discussion similaire il y a quelques mois. Le facteur décisif pour nous s'est résolu à la façon dont nous allions créer et mettre en œuvre chaque technologie. Comme nous étions déjà en train de créer une application MVC et que nous utilisions Knockout.js pour la liaison de données, nous utilisions efficacement MVVM avec les contrôleurs simplement une API pour les données.
Cela nous a permis de classer notre utilisation des technologies avec ce projet comme suit:
- L'API Web serait utilisée comme notre API pour les appels knockout et Ajax, ce qui en ferait nos commandes pour le modèle MVVM. Notre logique métier pour l'application Web est enveloppée derrière cette couche à travers un certain nombre de classes et de référentiels et d'usines.
- WCF est ensuite utilisé pour notre magasin de données, exposant les données de notre base de données non seulement pour ce site Web, mais également pour tout autre site ou service qui a consommé les données exposées.
Bien que cela ne soit pas une réponse populaire ou hyper technique, déterminer ce dont vous avez besoin en premier et comment ou si la technologie vous aidera est ce qui a aidé mon équipe à décider quelle technologie utiliser et où.
Mis à part la gestion d'équipe, vous ne choisissez pas l'un plutôt que l'autre. Vous devez examiner l'objectif de chaque service Web et utiliser la technologie appropriée pour la partie spécifique de l'application. C'est comme interdire les procédures de magasin lorsque l'équipe utilise le framework d'entité.
Notre utilisation serait principalement pour le Web, et nous exposerions nos services sur HTTP. Dans certains cas (disons 5 à 10%), nous pourrions avoir besoin de transactions distribuées.
Ensuite, vous écrivez ces 5 à 10% de services Web dans WCF. Si le service doit être référencé en interne dans d'autres projets, il n'y a pas de débat. L'avantage de la possibilité d'importer un contrat WCF pour créer le proxy client n'est PAS ouvert à la discussion. Il prend toute l'intégration, l'efficacité et la sécurité de type à un tout nouveau niveau.
Vous écrivez ce qui doit être utilisé pour les demandes d'API publiques (peut-être)/Ajax dans l'API Web Asp.net.
S'il ne s'agit que d'un appel ajax spécifique à une page, vous pouvez simplement utiliser Asp.Net MVC.
Ne choisissez pas, embrassez-les tous. Les API Web WCF et Asp.net ont des objectifs différents. Personne ne dit que vous ne pouvez pas avoir Apple et orange à la fois dans votre salade de fruits. Essayer de cueillir l'un sur l'autre et de le pousser dans chaque scénario n'est que pure paresse.
En d'autres termes, nous ferions mieux d'utiliser l'API Web, si nous voulons exposer un service sur HTTP, mais utiliser WCF en ce qui concerne TCP et Duplex.
Ce serait l'approche la plus raisonnable. Il est assez courant d'avoir à la fois des services WCF et WebApi dans la même application Web où les deux servent des objectifs différents.
Juste pour corriger quelques arguments:
Les modèles WCF ne sont pas POCO, en raison de [DataContract] & [DataMember] et de ces attributs
Dans de nombreux cas, les modèles WCF fonctionnent sans les attributs datacontract/datamember.
SOAP n'est pas aussi lisible et pratique que JSON
Ce n'est pas vrai, mais les services Web WCF transportent généralement du XML brut plutôt que du SOAP gonflé. C'est certainement est lisible.
Un argument pour WCF: s'il y a un WSDL disponible, il y a des tonnes d'outils dans presque toutes les technologies qui peuvent créer des proxy à partir des métadonnées. En revanche, le schéma JSON n'est pas encore largement pris en charge.
Pourquoi ne pas marcher avec WCF Data Services? Belles requêtes de style OData/webapi et facilité d'utilisation avec les pouvoirs de WCF, et la possibilité de renvoyer JSON très bien. De plus, Wcf n'est pas si mal si vous avez un bon code d'hébergement wcf automatique comme celui-ci:
https://github.com/ImaginaryDevelopment/MvcOdata
Je dirais qu'ils ne sont pas du tout séparés, sauf que lorsque nous sommes allés utiliser WebApi sur le front end et WCF data services au niveau intermédiaire, le WebApi a jeté sur des choses simples comme string contains ou string matching odata operators.
Un bon architecte retarde les décisions technologiques jusqu'à ce qu'elles soient absolument nécessaires.
En d'autres termes, ne prenez pas de décision tant qu'un client n'a pas réellement besoin de se connecter. Vous pouvez créer une couche de service entièrement testée sans mettre réellement un mécanisme de transport/communication dessus. 95% + du travail peut être effectué "sous" l'adaptateur, en dehors du cadre.
Le moment venu d'exposer ces services à des clients distants, vous pouvez choisir le framework le plus tendance du marché et écrire des wrappers fins sur une couche de service polyvalente.
Enfer, si votre "vraie" couche de service est bien faite, vous pouvez même essayer plusieurs wrappers à moindre coût.
C'est la réponse dogmatique, de toute façon. En pratique, vous voudrez peut-être choisir le outil le plus simple prêt à l'emploi pour faciliter les tests d'intégration rapides et fréquents - mais, limitez toujours votre dépendance à son égard et traitez-le strictement comme un simplement couche mince de communication sur les services réels .
Si vous adoptez cette approche, vous constaterez probablement que vous choisissez l'outil le plus simple à utiliser au départ et que personne ne fera d'histoires , car l'équipe sait qu'elle peut implémenter plus tard un outil ou un cadre plus sophistiqué ou à la mode, si nécessaire , avec un effort minimal.
Par conséquent, je suis confronté au même choix maintenant, je me suis demandé quel est le sous-ensemble des fonctionnalités de WCF que notre équipe utilise actuellement. Utilisons-nous différents protocoles? Non. Utilisons-nous le support des transactions? Non (bien que nous utilisions d'éventuels mécanismes de cohérence personnalisés). Utilisons-nous le duplex? Non.
Pourquoi aimerions-nous utiliser l'API Web? Intégration frontale plus facile (supprime la couche de service supplémentaire existante actuellement), SignalR pour pousser la réponse aux clients, mise en cache pour les GET.
Peut-être, on pourrait trouver d'autres raisons :) De même, des raisons de rester avec WCF.
Je voudrais demander quel modèle d'interaction devez-vous soutenir? Votre interface externe souhaitée ressemble-t-elle davantage à RPC ou REST? D'après mon expérience, c'est généralement quelque part entre mais surtout l'un ou l'autre.
Consommez-vous vos propres services pour d'autres projets dans .Net? C'est probablement la question la plus révélatrice que vous puissiez poser. WCF a l'avantage de pouvoir résumer vos interfaces dans une bibliothèque de classes distincte et de pouvoir construire et injecter votre client. En tant qu'extension, vous pouvez monter votre projet basé sur WCF avec des points de terminaison JSON et SOAP/WSDL, je l'ai fait. WCF offre également de meilleures garanties contre vos interfaces définies.
Cela dit, si vous vous attendez à avoir des clients d'autres plates-formes XML en général, et encore moins SOAP a une surcharge mesurable au-delà de ce que les points de terminaison JSON simples ont. Si vous choisissez la route JSON/API Web, alors vous devrez devenir bien meilleur pour documenter comment interagir avec vos points de terminaison et votre API.
En général, je suggère d'écrire un document API simple qui indique comment vous allez soumettre des données et comment vous souhaitez une réponse pour une structure d'objet de demande unique. Écrivez votre scénario de test de la manière la plus universelle et documentez-le comme tel. Je recommanderais une simple déclaration curl. Demandez ensuite à plusieurs de vos membres de l'implémenter à l'aide de WCF et de l'API Web. Voyez ensuite qui gagne.
Personnellement, bien que j'aie réalisé des projets et des implémentations relativement importants avec WCF, je penche en fait vers l'implémentation la plus simple qui, à mon avis, est en fait WCF avec l'utilisation des résultats JSON et certains comportements de substitution dans Global.asax.cs pour gérer les conditions d'erreur. Si la documentation d'une API comprend des instructions curl et que vous pouvez utiliser toutes les fonctionnalités de votre API avec des exemples de boucles, il devient beaucoup plus facile pour les clients d'être implémentés dans n'importe quel langage prenant en charge les interfaces Web. C'est vraiment là que WCF commence à tomber. Avoir une API bien définie avec une documentation agnostique est mieux que d'avoir des structures avec des outils automatisés lorsque vous traitez avec des systèmes étrangers. Parler en tant que consommateur de ces systèmes à partir d'autres plates-formes.
Au-delà de cela, implémentez votre client dans deux langues différentes. Faites un client en C #, mais faites-en également un dans Node.js ou Python et voyez à quel point ils s’adaptent réellement. Cet exercice à lui seul vous aidera à vous débarrasser des extrémités libres de votre API.
Si j'étais à votre place, je commencerais par examiner les capacités de vos équipes. Si tout le monde dans votre équipe connaît déjà WCF et seul un petit pourcentage connaît l'API Web, votre décision est déjà prise pour vous.
Bien sûr, si vous avez le temps, investissez-le dans l'apprentissage et l'amélioration de votre base de connaissances, mais pas au détriment des besoins et de la productivité de l'entreprise.