13518219792
这篇文章主要讲解了“WCF性能是怎样的”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“WCF性能是怎样的”吧！
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、虚拟空间、营销软件、网站建设、兴山网站维护、网站推广。
随着时代的发展，Microsoft推出的WCF被我们越来越多的人使用，我们就WCF性能分析一下，设计、构建、维护和版本控制分布式应用时一个复杂的任务。安全性、可靠性、事务性和伸缩性的因素和任务变得更加复杂。因为问题的复杂性，所以WCF被设计来解决这些问题，WCF是相当复杂的技术。为了能看清WCF性能，我把主要的功能分为10个类别：独立版本控制、异步只进消息、平台统一、安全性、可靠性、事务支持、互操作性、性能、扩展性和配置性。
独立版本控制
应用系统版本控制已经成为一个头疼的问题。如我之前提到的，面向组件的设计不能在分布式应用中很好地解决这些问题。任何技术如果在分布式世界里获得认可，必须允许分布式应用的不同部分能够独立的版本控制。遵照WS-*规范，关注WS-*关于消息定义的内容，允许被调用的服务可以再不同速率开发。这些特性不像创建WCF应用的底层原理那么重要，但是我认为这是使用WCF最重要的副产品。
异步单向消息
我们的许多应用是使用请求-响应模式调用功能的。典型的是，我们调用一个功能，然后等待结果返回，然后根据返回结果执行。这种方式在Internet上尤为多见。每次我们请求一个页面，我们必须等待网页的响应。局限我们的条件，大部分分布式应用使用的都是请求-响应方式。尽管开始看起来不自然，对于穿越 IO边界的任务分布式应用，异步只进消息方式是更加高效的方式。我认为这是使用WCF的又一个好处。异步只进消息方式允许使用高效的处理资源，更加方便地使用分布式应用的高级的功能、可靠性和相应能力。
平台统一
过去微软已经发布的很多分布式技术;有些成为WCF诞生的重要的导向技术。并且许多技术依然在使用。例如，在WCF发布以前，微软支持5种主要的分布式技术： RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。过去，***的分布式技术取决于应用系统的需求。例如，假如分布式应用都是基于.NET Framework，那么会选择.NET Remoting，因为它是.NET Remoting应用程序之间一种高效的通信方式。如果一个应用需要担保消息传输和持久化，那么MSMQ是***的选择。两个技术有不同的API、编程方式、操作要求和配置需求。结果，应用程序代码紧密地绑定到这些技术上，这些技术也绑定到特定的功能上。一些新的技术允许我们组合特性，比如事务性和队列性的COM+。只要需求不改变或者不使用其它的不支持的方式，这种模式是可以工作的。
什么是你的应用系统与其他的 .NET Framework应用、非 .NET Framework应用和支持事务的处理通信所需要的？在WCF之前，没有好的选择，本质上讲，这些需求使得开发者要么放弃一个需求要么编写自己的通信技术。与旧的技术相比，WCF能够集成旧的技术特性并且统一为一个编程模型，如表1-1所示。
表1-1 WCF特性对比
Feature | WSE | ASMX | Remoting | COM+ | MSMQ | WCF |
|---|---|---|---|---|---|---|
WS-* support | X | X | X | |||
Basic Web service interoperability | X | X | X | |||
.NET -to-.NET communication | X | X | ||||
Distributed transactions | X | X | X | |||
Queued messaging | X | X |
客观地说，WCF性能没有提供给我们无约束连接的特性，但是确实提供给了我们比以更多的连接特性。
感谢各位的阅读，以上就是“WCF性能是怎样的”的内容了，经过本文的学习后，相信大家对WCF性能是怎样的这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
