WCF élève-t-il la barre ou simplement le niveau de complexité? [fermé]

Je comprends la valeur du modèle service / hôte / client en trois parties offert 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 générer le proxy? Avec les services ASMX, un faisceau de test était 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 avantages 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, sous forme de tutoriel) est Learning WCF de Michele Leroux Bustamante. Il a de bons endroits mais il est désuet et son site Web correspondant a disparu.

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

Ok, on y va. Tout d'abord, le livre de Michele Leroux Bustamante a été mis à jour pour VS2008. Le site Web du livre n'a pas disparu. Il est en place pour le 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 obtiendrez la réimpression qui est mise à jour.

WCF ne remplace pas seulement ASMX. Bien sûr, il peut (et le fait 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 hautement 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 vraiment à 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 du service avec très peu de code. En utilisant cette méthode, vous avez un contrôle total sur l'implémentation. Quelle que soit la méthode que vous choisissez pour générer une classe proxy, Michele montre les deux et les utilise dans son excellente série de webémissions sur le sujet.

Michele a des tonnes de matériel formidable, et je vous recommande de consulter son (ses) site (s) Web. Voici quelques liens qui m'ont été extrêmement utiles alors que j'apprenais WCF. J'espère que vous vous rendrez compte à quel point WCF est vraiment fort 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 la peine:

• Webémissions de Michele: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• Site Web du livre de Michele (vivant et mis à jour pour VS2008): http://www.thatindigogirl.com/

Je vous recommande de regarder au moins 1 des webémissions de Michele. Elle est une présentatrice très efficace et elle est évidemment incroyablement compétente en matière de WCF. Elle fait un excellent travail de démystification du fonctionnement interne de WCF à partir de zéro.

J'utilise généralement Google pour trouver mes réponses WCF et je me retrouve généralement sur les blogs suivants:

Blogs avec des articles WCF précieux

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

Autres articles précieux que j'ai trouvés

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

J'ai du mal à voir quand je devrais ou utiliserais WCF. Pourquoi? Parce que je place la productivité et la simplicité en tête de ma liste. Pourquoi le modèle ASMX a-t-il été si réussi, parce qu'il a fonctionné et que vous le faites fonctionner rapidement. Et avec VS 2005 et .NET 2.0 wsdl.exe crachait des services assez 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 hérités, écrivez-leur des adaptateurs spécifiques afin qu'ils puissent jouer dans le beau et beau monde SOA.

WCF est beaucoup plus puissant que ASMX et il l'étend de plusieurs manières. ASMX est limité à HTTP uniquement, alors que WCF peut utiliser plusieurs protocoles pour sa communication (d'accord, HTTP est toujours la façon dont la plupart des gens l'utiliseront, au moins pour les services qui doivent être interopérables). WCF est également plus facile à étendre. Au moins, il est possible de l'étendre de manière à ce qu'ASMX ne puisse pas être étendu. "Facile" peut l'étirer. =)

La fonctionnalité ajoutée offerte par WCF l'emporte de loin sur la complexité qu'elle ajoute, à mon avis. J'ai aussi le sentiment que le modèle de programmation est plus simple. Les DataContracts sont bien plus agréables que d'avoir à sérialiser à l'aide de la sérialisation XML avec des propriétés publiques pour tout, par exemple. C'est aussi de nature beaucoup plus déclarative, ce qui est également bien.

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

Je ne le vois pas assez souvent mentionné, mais vous pouvez toujours implémenter 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 de données, de service et d'opération séparés 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 dans les coulisses.

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, canaux nommés ou transports MSMQ.

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

Si vous utilisez VS2008 et créez un projet WCF, vous obtenez automatiquement un faisceau 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 la WCF étaient exactement les mêmes! Voici quelques solutions:

1. Programmez votre propre couche proxy / client en utilisant des génériques (voir les classes ClientBase , Binding). J'ai trouvé cela facile à mettre en œuvre, mais difficile à perfectionner.
2. Utiliser une implémentation tierce de 1 ( SoftwareIsHardwork est mon préféré actuel)

WCF remplace tous les services Web antérieurs technologies de de Microsoft. Il fait également beaucoup 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é beaucoup plus élevé de flexibilité et de portabilité en faisant les choses dans 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 offertes 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 fichier de configuration mod. 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 que l'un de ces nombreux moyens et est donc maintenant regroupé sous le parapluie de capacités WCF.

Les services Web ne sont accessibles que 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 pour l'hébergement de services WCF sont IIS, WAS, auto-hébergement, service Windows géré.

La principale différence est que les services Web utilisent XmlSerializer. Mais WCF utilise DataContractSerializer qui est meilleur en performances par rapport à 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 de trafic ou autre
• 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 les données et les présente dans un
• présentation. Exposer un workflow implémenté à l'aide de Windows Workflow
• Foundation en tant que service WCF. Une application Silverlight pour interroger un
• service pour les derniers flux de données.

Caractéristiques de WCF

• Orientation du service
• Interopérabilité
• Modèles de messages multiples
• Métadonnées du service
• Contrats de données
• Sécurité
• Transports et encodages multiples
• Messages fiables et mis en file d'attente
• Messages durables
• Transactions
• Prise en charge AJAX et REST
• Extensibilité

source: principale source de texte

MSDN? Je fais 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. Pour ne pas dire qu'ils n'ont pas essayé d'être compatibles avec d'autres consommateurs; mais le modèle n'a pas été conçu pour s'adapter à d'autres pages Web ASP.NET et à 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 exemple REST, JSON, etc. en plus du SOAP habituel. D'autres personnes auront probablement beaucoup plus de facilité à consommer 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 la façon dont il est positionné et comment il est utilisé en interne par Microsoft, il s'agit vraiment d'une pièce d'architecture fondamentale qui est utilisée pour tout type de communication transfrontalière.

Je crois que WCF fait vraiment progresser l'implémentation des services Web ASMX de plusieurs manières. Tout d'abord, il fournit un très beau modèle d'objet en couches qui aide à masquer la complexité intrinsèque des applications distribuées. Deuxièmement, vous pouvez avoir plus que des modèles de messagerie de demande-réexécution, 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 ainsi prendre en charge avec élégance HTTP, HTTPS, TCP et autres. La rétrocompatibilité avec les services Web de "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 à XML» comme JSON.

Les choses difficiles que je trouve avec WCF sont la gestion des configurations pour les clients et les serveurs, et le dépannage des exceptions d'état défectueuses pas si gentilles.

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

Je trouve que c'est une douleur; en ce que j'ai .NET aux deux extrémités, j'ai les mêmes dlls «contract» chargées aux deux extrémités, etc.

Par défaut, WCF autorise uniquement 1 ou 2 clients à se connecter à un service jusqu'à ce que vous modifiiez beaucoup de configuration. Changer la configuration à partir du code n'est pas facile, expédier beaucoup de fichiers comfig n'est pas une option, car il est trop difficile de fusionner nos modifications avec les modifications qu'un client peut avoir apportées au moment d'une mise à niveau (nous ne voulons pas non plus de clients jouer avec les paramètres WCF!)

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

Je pense essayer de faire semblant que les communications basées sur des objets .NET vers .NET équivaut à envoyer un peu de texte (xml) à un système inconnu, était un pas trop loin.

(Les quelques fois où nous avons utilisé WCF pour parler à un système Java, nous avons constaté que le XSD que le système java a donné ne correspondait pas au XML qu'il voulait de toute façon, nous avons donc dû coder à la main un grand nombre de mappages XML.)