Le projet actuel que je travaille est de largement à l'aide de services Web et est fabriqué dans .NET 3.5. Maintenant que nous allons pour la mise en œuvre de la deuxième phase, nous sommes confondus si nous devrions utiliser un service wcf ou un service Web tel que fait précédemment? Y a-t-il autre chose de nouveau qui peut être utile et propose .NET 4.0 concernant les services Web ou wcf.
6 Réponses :
Nous venons de terminer un tout nouveau projet à l'aide de WCF au lieu des services Web ASMX pour la première fois. Nous sommes très heureux des résultats, mais savons qu'il y avait une courbe d'apprentissage escarpée. Malgré tout, nous sommes extrêmement satisfaits des résultats globaux et savons que c'est la base de tout ce que Microsoft fait de l'avant et qu'elle mérite totalement la douleur - les verrues et tous.
Avantages rapides que nous avons gagné sur ASMX :
1) Pour les appels de services internes (derrière pare-feu), nous utilisons le filet: la liaison TCP, qui est beaucoup plus rapide que le savon
2) Nous avons activé à la fois un point final TCP et un point d'extrémité "Web" sur le même service avec une seule mise à jour de fichier de configuration (aucun changement de code)
3) Nous avons pu créer des services Web reposants AJAX-supportant uniquement les modifications de la configuration et l'utilisation du DatacontractjsonSerializer qui est déjà intégré. Pour ce faire, nous aurions dû écrire un gestionnaire HTTP (ASHX) et gérer la plupart des La sérialisation et l'URL JSON analysent à la main.
4) Comme notre site doit être à l'échelle de l'optimisation et de la stabilité des performances, nous examinons la conversion à l'utilisation d'une structure de messagerie basée sur MSMQ qui est asynchrone et garantie et participe aux transactions; WCF fournit une liaison msmq qui nécessite un changement de code peu à aucun code dans nos services - juste des mises à jour de référence et la configuration correctement MSMQ avec les services existants (et ajout d'attributs pour les limites transactionnelles).
Mais soyez averti: Investissez vraiment dans l'apprentissage de cette (achetez le Blue O-Reily Book et passez-le). Il existe des choses comme des arguments-nom-nom-changement pendant le développement qui ne cassent réellement pas les références de service, mais aboutissent à des arguments nuls éduqués (la version intégrée de la manutention), d'hébergement de modèles à considérer (Service Windows vs. IIS) et à l'instanciation modèles et défaillances exceptionnels à tous bien comprendre. Nous n'y sommes entrés et nous avions des douleurs. Mais nous avons labouré à l'avance et sommes très heureux de nos apprentissages et de la flexibilité et des opportunités de croissance que nous n'avons plus liées à ASMX!
Tony est la mise à jour de la valeur des efforts ... Je veux dire que vous voyez une amélioration de performance, de fonctionnalité et de flexibilité considérable lors de la commutation d'ASMX en WCF?
Quelques informations supplémentaires sur les performances ici: msdn.microsoft.com/en-us/Library /bbb310550.aspx
Hottaster - oui, oui, oui. Encore une fois, avec un grand pouvoir vient une grande responsabilité de l'apprendre. Mais tout ça vaut la peine. La performance vaut mieux ne pas utiliser le savon sur HTTP dans les services internes, mais vous pouvez facilement exposer les points d'extrémité Web pour les mêmes services en cas de besoin avec configuration.
@Tony sur le point (3) - avec ASMX, vous pouvez activer la sérialisation JSON en décorant votre méthode avec attribut [scriptMethod (ResponseFormat = ResponFormat.json)]. Néanmoins, bon post.
Il existe différents points à prendre en compte avant de sauter sur WCF:
- WCF est architecturalement plus robuste et favorise les meilleures pratiques.
- Si vous savez ce que vous faites son "soyeux lisse", sinon vous êtes pour un Ride.
- Avez-vous assez de temps pour compléter la conversion de vos services?
Enfin, je dirais que si vous avez le temps, la bling et le muscle à faire la mise à niveau. Ça en vaut la peine. Si ASMX satisfait à tous les besoins, vous pouvez persister avec les services Web.
Deux autres aspects:
Quelle que soit la manière dont vous choisissez ceci pour le côté serveur, vous pouvez facilement consommer des services WebServices et WCF en utilisant uniquement WCF sur le côté client. Ceci est de valeur, si vous consommez plusieurs services avec un seul client.
Vous avez demandé des thèmes à venir. Si vous envisagez Cloud Computing: il est possible d'héberger des services de WCF sur Windows Azure.
ASMX est grande et simple - mais il est très limité à bien des égards:
remèdes WCF - et cette offre beaucoup plus au-delà. Vous pouvez héberger vos services WCF dans IIS - ou auto-hôte dans une application console ou Win NT Service, comme besoin est. Vous pouvez connecter vos services WCF via HTTP, TCP / IP, MSMQ, les protocoles peer-to-peer, les canaux nommés pour les communications sur la machine et bien plus encore.
Je recommande vivement vous allez avec WCF. Il est un peu plus complexe que ASMX, mais il offre aussi juste sooo beaucoup plus les capacités et les choix!
En ce qui concerne resoures: il y a MSDN WCF Developer Center qui a tout de didacticiels pour débutants aux articles et échantillon code.
En outre, je vous recommandons de jeter un oeil à l'écran Pluralsight moulages sur WCF - c'est une excellente série allant de « Création de votre première service WCF" et " création de votre premier client de WCF " tout le chemin aux sujets plutôt avancés. Aaron Skonnard très bien explique tout en 10-15 minutes screencasts - fortement recommandé
avec WCF ou ASMX, assurez-vous d'ajouter vos services à vos pages à l'aide de la balise ASP: scriptManager. Il construira des proxy JavaScript pour vous et l'avantage est que vous n'avez pas besoin de construire du tout à analyser, quel que soit le protocole sous-jacent. C'est très très gentil. Cet exemple est ASMX, mais il est tout aussi propre que l'utilisation de la WCF.
function editLocation(id) {
vRIS.HospitalLocationService.GetByID(id, getComplete, getError);
}
function getComplete(results, context, methodName) {
document.all['txtLocation'].value = results.Location;
document.all['txtInterfaceID'].value = results.InterfaceID;
document.all['selActive'].value = results.Active ? "true" : "false";
document.all['hdnLocationID'].value = results.ID.toString();
}
function getError(errorInfo, context, methodName) {
Alert(methodName + " : " + errorInfo);
document.all['txtLocation'].value = "";
document.all['txtInterfaceID'].value = "";
document.all['selActive'].value = "false";
document.all['hdnLocationID'].value = "";
}
Le modèle WCF est considérablement plus flexible, essentiellement - si vous Une brève liste des différences cependant: