WCF relève-t-il la barre ou simplement le niveau de complexité ?

StackOverflow https://stackoverflow.com/questions/50114

  •  09-06-2019
  •  | 
  •  

Question

Je comprends la valeur du modèle en trois parties service/hôte/client proposé par WCF.Mais est-ce juste moi ou semble-t-il que WCF a pris quelque chose d'assez direct et simple (le modèle ASMX) et en a fait un gâchis ?

Existe-t-il une alternative à l'utilisation de la ligne de commande de SvcUtil pour remonter le temps pour générer le proxy ?Avec les services ASMX, un harnais de test a été automatiquement fourni ;existe-t-il une bonne alternative aujourd'hui avec WCF ?

J'apprécie que les éléments WS* soient plus étroitement intégrés à WCF et j'espère y trouver des bénéfices pour WCF, mais bon sang, sinon je suis perplexe.

En outre, l’état des livres disponibles pour WCF est au mieux épouvantable.Juval Lowy, un superbe auteur, a écrit un bon livre de référence O'Reilly "Programming WCF Services" mais il ne fait pas grand-chose (pour moi en tout cas) pour apprendre maintenant à utiliser WCF.Le précurseur de ce livre (et un peu mieux organisé, mais pas beaucoup, en tant que tutoriel) est Learning WCF de Michele Leroux Bustamante.Il a de bons spots mais est obsolète et son site Web correspondant a disparu.

Avez-vous de bonnes références d'apprentissage WCF en plus de simplement continuer à rechercher des choses sur Google ?

Était-ce utile?

La solution

Bon, c'est parti.Premièrement, le livre de Michele Leroux Bustamante a été mis à jour pour VS2008.Le site Web du livre n’a pas disparu.Il est en ligne en ce moment et contient des tonnes d'informations intéressantes sur la WCF.Sur ce site Web, elle fournit un code mis à jour compatible avec VS2008 pour tous les exemples de son livre.Si vous commandez sur Amazon, vous recevrez la réimpression qui est mise à jour.

WCF n'est pas seulement un remplacement pour ASMX.Bien sûr, il peut (et fonctionne très bien) remplacer ASMX, mais le véritable avantage est qu'il permet à vos services d'être auto-hébergés.La plupart des fonctionnalités de WSE ont été intégrées dès le départ.Le cadre est très configurable, et la capacité de servir plusieurs points de terminaison sur plusieurs protocoles est incroyable, IMO.

Bien que vous puissiez toujours générer des classes proxy à partir de l'option « Ajouter une référence de service », ce n'est pas nécessaire.Tout ce que vous avez à faire est de copier votre interface ServiceContract et d'indiquer à votre code où trouver le point de terminaison du service, et c'est tout.Vous pouvez appeler des méthodes depuis le service avec très peu de code.En utilisant cette méthode, vous avez un contrôle total sur la mise en œuvre.Quelle que soit la méthode que vous choisissez pour générer une classe proxy, Michele affiche les deux et les utilise dans son excellent série de webémissions sur le sujet.

Michele propose des tonnes de matériel intéressant et je vous recommande de consulter son (ses) site (s) Web.Voici quelques liens qui m'ont été incroyablement utiles pendant que j'apprenais WCF.J'espère que vous réaliserez à quel point WCF est puissant et à quel point il est facile à mettre en œuvre.La courbe d'apprentissage est un peu raide, mais les récompenses pour votre investissement en temps en valent bien la peine :

Je vous recommande de regarder au moins une des webémissions de Michele.C'est une présentatrice très efficace et elle est évidemment incroyablement compétente en matière de WCF.Elle fait un excellent travail en démystifiant le fonctionnement interne de la WCF de fond en comble.

Autres conseils

J'ai du mal à voir quand je devrais ou utiliserais WCF.Pourquoi?Parce que je mets la productivité et la simplicité en tête de ma liste.Pourquoi le modèle ASMX a-t-il connu un tel succès, parce qu'il a fonctionné et qu'il fonctionne rapidement.Et avec VS 2005 et .NET 2.0, wsdl.exe crachait des services plutôt sympas et conformes.

Dans la vraie vie, vous devriez avoir très peu de protocoles de communication dans votre architecture.Cela reste simple et maintenable.Si vous avez besoin d'accéder à des systèmes existants, écrivez des adaptateurs spécifiques pour eux afin qu'ils puissent jouer dans le monde SOA, brillant et magnifique.

WCF est beaucoup plus puissant que ASMX et l'étend de plusieurs manières.ASMX est limité uniquement à HTTP, alors que WCF peut utiliser plusieurs protocoles pour sa communication (il est vrai que HTTP reste la manière dont la plupart des gens l'utiliseront, du moins pour les services qui doivent être interopérables).WCF est également plus facile à étendre.Au moins, il est possible de l'étendre d'une manière où ASMX ne peut pas être étendu."Facile" est peut-être un étirement.=)

La fonctionnalité supplémentaire offerte par WCF dépasse de loin la complexité qu'elle ajoute, à mon avis.Je pense également que le modèle de programmation est plus simple.Les DataContracts sont bien plus agréables que de devoir sérialiser en utilisant la sérialisation XML avec des propriétés publiques pour tout, par exemple.Il est également de nature beaucoup plus déclarative, ce qui est également agréable.

Attendez....avez-vous déjà utilisé .NET Remoting, car c'est la vraie chose qu'il remplace..NET Remoting est en soi assez compliqué.Je trouve WCF plus facile et mieux présenté.

Je ne le vois pas mentionné assez souvent, mais vous peut implémentez toujours des services assez simples avec WCF, très similaires aux services ASMX.Par exemple:

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

Vous devez toujours enregistrer le point final dans votre web.config, mais ce n'est pas si grave.

L'élimination de la verbosité des contrats séparés de données, de services et d'exploitation contribue grandement à rendre WCF plus gérable pour moi.

VS2008 inclut l'élément de menu contextuel « Ajouter une référence de service » qui créera le proxy pour vous en arrière-plan.

Comme mentionné précédemment, WCF n'est pas uniquement destiné à remplacer les types de services Web ASMX, mais à fournir une méthodologie cohérente, sécurisée et évolutive pour tous les services interopérables, que ce soit via HTTP, TCP, les canaux nommés ou les transports MSMQ.

J'avoue que j'ai d'autres problèmes avec WCF (par ex.réécriture des signatures de méthode lors de l'exposition d'un service via basicHTTP - voir ici, mais dans l'ensemble, je pense que c'est une nette amélioration

Si vous utilisez VS2008 et créez un projet WCF, vous obtenez automatiquement un harnais de test lorsque vous appuyez sur exécuter/déboguer et vous pouvez ajouter une référence sans avoir à utiliser svcutil.

Mes premières pensées sur WCF étaient exactement les mêmes !Voici quelques solutions :

  1. Programmez votre propre couche proxy/client en utilisant des génériques (voir classes Base de clientèle, Obligatoire).J'ai trouvé cela facile à mettre en œuvre, mais difficile à perfectionner.
  2. Utilisez une implémentation tierce de 1 (SoftwareIsHardwork est mon préféré du moment)

WCF est un remplacement pour tout ce qui était auparavant service Web technologies de Microsoft.Il fait également bien plus que ce qui est traditionnellement considéré comme des « services Web ».

Les « services Web » WCF font partie d’un spectre beaucoup plus large de communications à distance activées via WCF.Vous obtiendrez un degré de flexibilité et de portabilité beaucoup plus élevé en travaillant avec WCF qu'avec ASMX traditionnel, car WCF est conçu, dès le départ, pour résumer toutes les différentes infrastructures de programmation distribuées proposées par Microsoft.Un point de terminaison dans WCF peut être communiqué aussi facilement via SOAP/XML que via TCP/binaire et changer ce support est simplement un mod de fichier de configuration.En théorie, cela réduit la quantité de nouveau code nécessaire lors du portage ou de la modification des besoins, des cibles, etc.

ASMX is older than WCF, and anything ASMX can do so can WCF (and more).Fondamentalement, vous pouvez voir WCF comme essayant de regrouper logiquement toutes les différentes manières de faire communiquer deux applications dans le monde de Microsoft ;ASMX n’était qu’une de ces nombreuses méthodes et est donc désormais regroupé sous l’égide des capacités WCF.

Les services Web sont accessibles uniquement via HTTP et fonctionnent dans un environnement sans état, où WCF est flexible car ses services peuvent être hébergés dans différents types d'applications.Les scénarios courants d’hébergement des services WCF sont IIS, WAS, l’auto-hébergement et le service Windows géré.

La principale différence est que les services Web utilisent XmlSerializer.Mais WCF utilise DataContractSerializer qui offre de meilleures performances que XmlSerializer.

Dans quels scénarios WCF doit-il être utilisé

  • Un service sécurisé pour traiter les transactions commerciales.Un service qui
  • fournit des données actuelles à d'autres, comme un rapport sur la circulation ou d'autres
  • service de surveillance.Un service de chat qui permet à deux personnes de
  • communiquer ou échanger des données en temps réel.Une application de tableau de bord
  • qui interroge un ou plusieurs services pour obtenir des données et les présente de manière logique
  • présentation.Exposer un workflow implémenté à l'aide de Windows Workflow
  • Fondation en tant que service WCF.Une application Silverlight pour interroger un
  • service pour les derniers flux de données.

Caractéristiques de WCF

  • Orientation vers les services
  • Interopérabilité
  • Plusieurs modèles de messages
  • Métadonnées des services
  • Contrats de données
  • Sécurité
  • Transports et codages multiples
  • Messages fiables et en file d'attente
  • Messages durables
  • Transactions
  • Prise en charge d'AJAX et REST
  • Extensibilité

source: principale source de texte

MSDN ?Je me débrouille généralement assez bien avec la référence de la bibliothèque elle-même et je m'attends généralement à y trouver des articles précieux.

En termes de ce qu’il offre, je pense que la réponse est la compatibilité.Les services ASMX étaient plutôt Microsofty.Cela ne veut pas dire qu’ils n’ont pas essayé d’être compatibles avec les autres consommateurs ;mais le modèle n'a pas été conçu pour s'adapter à grand-chose en dehors des pages Web ASP.NET et de certains autres consommateurs Microsoft personnalisés.Alors que WCF, en raison de son architecture, permet à votre service d'avoir des points de terminaison basés sur des standards très ouverts, par ex.REST, JSON, etc.en plus du SAVON habituel.D'autres personnes auront probablement beaucoup plus de facilité à utiliser votre service WCF que votre service ASMX.

(Tout cela est essentiellement déduit de la lecture comparative de MSDN, donc quelqu'un qui en sait plus devrait se sentir libre de me corriger.)

WCF ne doit pas être considéré comme un remplacement d'ASMX.À en juger par son positionnement et la manière dont il est utilisé en interne par Microsoft, il s'agit en réalité d'un élément d'architecture fondamental utilisé pour tout type de communication transfrontalière.

Je pense que WCF fait réellement progresser la mise en œuvre des services Web ASMX à bien des égards.Tout d’abord, il fournit un très joli modèle objet en couches qui permet de masquer la complexité intrinsèque des applications distribuées.Deuxièmement, vous pouvez avoir plus que des modèles de messagerie de requête-relecture, y compris des notifications asynchrones du serveur au client (impossible avec HTTP pur), et troisièmement, extraire le protocole de transport sous-jacent de la messagerie XML et prendre ainsi en charge avec élégance HTTP, HTTPS, TCP et autres.La rétrocompatibilité avec les web services « 1ère génération » est également un plus.WCF utilise la norme XML comme format de représentation interne.Cela pourrait être perçu comme un avantage ou un inconvénient, en particulier avec la popularité croissante des « alternatives sans gras au XML » comme JSON.

Les choses difficiles que je trouve avec WCF sont la gestion des configurations des clients et des serveurs, et le dépannage des exceptions d'état défaillantes pas si agréables.

Ce serait formidable si quelqu'un avait des raccourcis ou des conseils pour ceux-ci.

Je trouve que c'est pénible;en ce sens que j'ai .NET aux deux extrémités, j'ai les mêmes DLL "contrat" ​​chargées aux deux extrémités, etc.Mais ensuite, je dois m'occuper de beaucoup de détails comme les attributs "KnownType".

WCF par défaut ne permet également qu'à 1 ou 2 clients de se connecter à un service jusqu'à ce que vous modifiiez beaucoup de configuration.Changer la configuration à partir du code n'est pas facile, envoyer de nombreux fichiers comfig n'est pas une option, car il est trop difficile de fusionner nos modifications avec les modifications qu'un client a pu apporter au moment d'une mise à niveau (nous ne voulons pas non plus que les clients jouer avec les paramètres WCF !)

La communication à distance .NET avait tendance à fonctionner la plupart du temps.

Je pense qu'essayer de prétendre que les communications basées sur des objets .NET vers .NET reviennent à envoyer un peu de texte (xml) à un système inconnu, c'était un pas de trop.

(Les rares fois où nous avons utilisé WCF pour communiquer avec un système Java, nous avons constaté que le XSD fourni par le système Java ne correspondait pas au XML qu'il souhaitait de toute façon, nous avons donc dû coder manuellement de nombreux mappages XML.)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top