Qu'est-ce qui me manque dans la WCF?

Question

J'ai été en développement dans MS technologies pour plus longtemps que je m'en souvienne, à ce stade. Lors de l' .NET est arrivé sur la scène, je pensais qu'ils frappé le clou sur la tête et à chaque itération et version je pensais que leurs technologies sont de plus en plus forte et se réjouissait à chaque version.

Cependant, ayant eu à travailler avec WCF pour la dernière année, je dois dire que j'ai trouvé la technologie très difficile de comprendre et de travailler avec. D'abord c'est assez intéressante, mais quand vous commencez à entrer dans les entrailles de la, la configuration est un cauchemar, d'avoir à remplacer les comportements pour les formats de message, nombre d'objets contenus dans un des messages, de la complexité du modèle de sécurité, l'élimination des procurations quand faillées et enfin de revenir à la définition d'interfaces dans le code plutôt qu'en XML.

Il n'a tout simplement pas travailler hors de la boîte et je pense qu'il devrait. Nous avons trouvé toutes les questions ci-dessus, bien que les tests nous-mêmes ou bien lors de nos produits ont été sur le site.

Je comprends la logique derrière tout ça, mais sûrement, ils pourraient venir avec de plus simple mécanisme de mise en œuvre.

Je suppose que ce que je demande est,

• Suis-je en regardant la WCF dans le mauvais sens?
• Quels sont les atouts-t-il au cours de la des solutions de rechange?
• Dans quelles circonstances dois-je choisissez d'utiliser WCF?

OK, les gars, Désolé pour la réponse tardive, ont une fâcheuse tendance à obtenir de la manière parfois :)

Quelques précisions Mon principal point de peinture avec WCF, je suppose, qui tombe dans les domaines suivants Alors que cela fonctionne hors de la boîte, de votre gauche à quelques grandes surprises sous le capot. Comme l'a souligné ci-dessus des choses de base sont limités jusqu'à ce qu'ils ne soient écrasés

1. La taille de la chaîne de caractères que peut être passé ne peut pas être plus de 8K
2. Nombre d'objets qui peuvent être transmis dans un seul message est limité
3. Les procurations ne pas récupérer automatiquement en cas de défaillance
4. Le montant de la configuration alors qu'il y est une bonne chose, mais comprendre tout ça et ce qu'il faut utiliser ce qui et dans quelles circonstances il peut être difficile à comprendre. Surtout lors du déploiement du logiciel sur le site avec les différentes exigences en matière de sécurité, etc. Lorsque l'on parle de configuration, nous avons dû nous cacher beaucoup de la nôtre dans un back-end de la base de données parce que la sécurité de réseau et les gens sur place étaient en train d'essayer de changer les choses dans les fichiers de configuration sans le comprendre.
5. Conserver la configuration des interfaces dans le code plutôt que de déplacer explicitement des interfaces définies dans le XML, qui peuvent être publiés et utilisés par presque n'importe quoi. Je sais que nous pouvons exporter les données XML à partir de l'assemblée, mais c'est plein de détritus et de certains générateurs de code s'étouffe.

Je sais que le monde bouge, je l'ai déplacé sur un certain nombre de fois au cours de la dernière (ahem 22 ans, j'ai été en développement) et suis activement en utilisant WCF, alors ne vous méprenez pas, je ne comprends ce que c'est et où il va.

Je pense juste qu'il devrait être plus simple de configuration/options de déploiement disponibles, plus facile à configurer et à une meilleure gestion de la configuration (config SQL fournisseur peut-être, plutôt que de simplement le web.config/app.les fichiers de configuration).

Answer 1

J'utilise tout le temps la WCF et je partage votre douleur. On dirait qu’il a été grossièrement sur-conçu, mais nous allons rester avec cela très longtemps, alors j’essaie de l’apprendre.

Une chose dont je suis certain, XML est nul. Je n'ai eu que des problèmes d'utilisation de XML pour le contrôler et depuis je me suis tourné vers la gestion de tout via le code.

Answer 2

Les préoccupations que vous avez énumérés ont été:

---

1. La taille de la chaîne de caractères que peut être passé ne peut pas être plus de 8K
2. Nombre d'objets qui peuvent être transmis dans un seul message est limité
3. Les procurations ne pas récupérer automatiquement en cas de défaillance
4. Le montant de la configuration alors qu'il y est une bonne chose, mais comprendre tout ça et ce qu'il faut utiliser ce qui et dans quelles circonstances il peut être difficile à comprendre. Surtout lors du déploiement du logiciel sur le site avec les différentes exigences en matière de sécurité, etc. Lorsque l'on parle de configuration, nous avons dû nous cacher beaucoup de la nôtre dans un back-end de la base de données parce que la sécurité de réseau et les gens sur place étaient en train d'essayer de changer les choses dans les fichiers de configuration sans le comprendre.
5. Conserver la configuration des interfaces dans le code plutôt que de déplacer explicitement des interfaces définies dans le XML, qui peuvent être publiés et utilisés par presque n'importe quoi. Je sais que nous pouvons exporter les données XML à partir de l'assemblée, mais c'est plein de détritus et de certains générateurs de code s'étouffe.

---

voici mon point de vue:

(1) a adressé une préoccupation légitime des clients avec ASMX. Il était trop grand ouvert, avec aucun moyen de le contrôler facilement. Le 8k limite est facilement levée si vous savez où chercher. Je suppose que vous pouvez compter que comme une surprise, mais c'est plus d'une chose une seule fois. Une fois que vous savez à ce sujet, vous pouvez le soulever et faire avec elle pour toujours, si vous choisissez.

(2) est également configurable.

(3) est connue, mais il y a des passe-partout de façons de contourner cela. Le StockTrader code pour l'exemple, montre un schéma éprouvé. Vous pouvez réutiliser le code dans votre propre application. Vous ne savez pas si c'est corrigé dans la WCF .NET 4.0. Je sais que c'était une demande d'ouverture.

(4) La config est une bête. C'est une préoccupation pour beaucoup de gens. Le problème ici est que la WCF est très flexible, et la config de tous que la flexibilité est exposée par le biais de fichiers xml. Il peut être écrasante. Une approche qui semble fonctionner est de prendre en petites bouchées, comme vous en avez besoin.

(5) je ne comprends pas.

Answer 3

Je préfère largement ASP.NET MVC et Web API sur WCF. Si je devais résumer la WCF pour un développeur qui vient d'être présenté à elle, je dirais, "WCF est un bien intentionnés tentent de le remplacer conçu, Java EE style RPC développement." Malheureusement, la plupart des décisions exigent que vous devenez un expert dans la configuration de bas niveau, sans importance éléments (taille des messages, les délais d'attente, sans intérêt que les éléments de protocole, etc.) tout en faisant abstraction absolument essentiel morceaux (à l'URL de la conception, la sérialisation des paramètres de réponse, la sérialisation, etc.). La différence dans la productivité et l'aggravation entre les équipes, je sais en utilisant WCF vs API Web est le jour et la nuit.

Pour venir nettoyer un peu: j'ai toujours détesté le concept de base .NET Remoting. J'ai l'impression que les développeurs ont besoin d'une compréhension approfondie de la structure des ressources de leur application et la façon dont ces ressources sont en série. En outre, l'utilisation de la "POST" du verbe simple à la récupération de données est inquiétante dans la lecture d'une application intense que les besoins à l'échelle.

Answer 4

Je vais aborder le reste de vos questions après clarification. En attendant, je peux répondre à votre question, lorsque vous devez choisir d'utiliser WCF: toujours.

WCF est le remplacement de l'ancien ASMX technologies, y compris WSE. Il est également le remplacement .NET Remoting. C'est la seule technologie à haut niveau de fonctionnalités de communication .NET sera la base pour un futur proche.

Considérons, par exemple, Windows Azure. Il n'était pas inévitable que le nouveau concept de "cloud computing", qui serait communications aspects couverts par la WCF. Pourtant, la WCF a été suffisamment flexible pour être étendu pour couvrir les cas, avec très peu de changements dans le code.

Si vous rencontrez des problèmes avec WCF, alors vous feriez bien de vous assurer que Microsoft sait à ce sujet. WCF est le présent et l'avenir du service web et d'autres services de développement orienté .NET, ils ont donc une incitation très forte pour vous écouter et de résoudre vos points de douleur. Soit contacter directement par le biais de Connecterou de poser des questions ici (balise avec WCF, s'il vous plaît), et beaucoup de gens vont vous aider.

Answer 5

Pour résoudre le problème de l'entretien cauchemar de l'application de config, certains standards comme UDDI ou WS-Discovery existent, WS-Discovery sera pris en charge par la WCF .NET 4.0.

Conserver la configuration de la les interfaces dans le code plutôt que de déménager explicitement définies dans les interfaces XML, qui peut être publié et consommée par presque n'importe quoi. Je sais que nous pouvez exporter les données XML à partir de la assembley, mais c'est plein de détritus et de certains générateurs de code s'étouffe.

Pouvez-vous être plus explicite ? Je pense que vous parlez du comportement en service configuré dans le code. Vous pouvez facilement le comportement du code des extensions pour configurer ce que vous êtes parle dans le fichier de configuration au lieu de code, MAIS je pense que si microsoft n'a pas fait cela il y a une bonne raison. Par exemple un service de ce comportement :

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)]

La mise en œuvre sait que l'instance n'est pas partagée entre plusieurs threads, donc il est développé différemment :

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]

Dans ce cas, le service de la mise en œuvre devrait prendre soin de concurency problèmes. La mise en œuvre est couplé avec l'attribut ServiceBehavior, de sorte que le déplacement de ce comportement dans un fichier XML n'est pas une bonne idée.

Que faire si vous pouvez modifier un InstanceContextMode.PerCall service à un InstanceContextMode.Service unique à l'intérieur du fichier de config ? Vous vous cassez la demande !