我在MS技术方面的开发时间超过了我在此阶段要记住的时间。当.NET到达现场时，我认为它们触及了头部，每次迭代和版本我认为他们的技术越来越强大，并期待每次发布。
然而，由于去年必须与WCF合作，我必须说我发现这项技术非常难以使用和理解。最初它非常吸引人但是当你开始深入了解它时，配置是一场噩梦，必须覆盖消息大小的行为，消息中包含的对象数量，安全模型的复杂性，出现故障时处理代理以及最终回到用代码而不是XML来定义接口。
它只是没有开箱即用，我认为应该。我们在测试自己时或者当我们的产品在现场时都发现了上述所有问题。
我确实理解这一切背后的基本原理，但他们肯定可以提出更简单的实施机制。
我想我要问的是，
好的朋友，对于延迟回复表示抱歉，工作确实有一种令人讨厌的习惯，有时会妨碍：）
一些澄清 我认为我与WCF的主要绘制点属于以下几个方面 虽然它开箱即用，但你的左侧还有一些重大的惊喜。如上所述，基本事物在被覆盖之前是受限制的
我知道世界在继续前进，我已经多次（最近22年来我一直在开发）并且积极使用WCF，所以不要误解我，我明白了这是它的目标和方向。
我认为应该有更简单的配置/部署选项，更容易的设置和更好的配置管理（SQL配置提供程序可能，而不仅仅是web.config / app.config文件）。
答案 0 :(得分：15)
我现在一直使用WCF，我分享你的痛苦。它似乎过于严重过度设计，但我们将长期坚持使用它，所以我正在努力学习它。
我确信一件事，XML很糟糕。我只有使用XML来控制它的问题，并且已经切换到通过代码处理所有内容。
答案 1 :(得分：8)
您列出的问题是：
这是我的看法：
（1）解决了客户对ASMX的有效担忧。它太开放了，无法轻易控制它。如果您知道要去哪里，可以轻松解除8k限制。我想你可以把它算作一个惊喜，但它更像是一次性的事情。一旦你了解它，你可以解除它，如果你愿意，可以永远完成它。
（2）也是可配置的。
（3）是众所周知的，但有一些样板方法可以解决这个问题。例如，StockTrader代码演示了一种经过验证的模式。您可以在自己的应用中重复使用该代码。不确定这是否在WCF for .NET 4.0中得到修复。我知道这是一个公开的请求。
（4）配置是野兽。这是很多人关注的问题。这里的问题是WCF非常灵活，所有这些灵活性的配置都是通过xml文件公开的。它可能是压倒性的。一种似乎有用的方法是在需要的时候将它放在小口中。
（5）我不明白。
答案 2 :(得分：7)
我非常喜欢基于WCF的ASP.NET MVC和Web API。如果我不得不将WCF总结给刚刚介绍它的开发人员，我会说，“WCF是一个很好的尝试来取代过度设计的Java EE风格的RPC开发。”不幸的是，许多决策要求您成为配置低级别，不重要的项目（消息大小，超时，不感兴趣的协议元素等）的专家，同时抽象绝对关键的部分（URL设计，参数序列化，响应序列化等）。 ）。我知道使用WCF与Web API的团队之间的生产力和恶化程度的差异是白天和黑夜。
要清理一下：我一直很讨厌.NET Remoting的核心概念。我觉得开发人员需要彻底了解他们的应用程序的资源结构以及这些资源是如何序列化的。此外，在需要扩展的读取繁重的应用程序中使用“POST”动词进行简单的数据检索是令人担忧的。
答案 3 :(得分：5)
我会在澄清之后解决你的其他问题。与此同时，我可以解决您何时应该选择使用WCF的问题：总是。
WCF是旧ASMX技术的替代品，包括WSE。它也是.NET Remoting的替代品。它是.NET中高级通信功能基于可预见的未来的唯一技术。
例如，考虑使用Windows Azure。 “云计算”这一新概念在WCF中涵盖其通信方面并非不可避免。然而，WCF足够灵活，可以扩展到覆盖这些情况，代码变化很小。
如果您遇到WCF问题，那么您最好确保Microsoft了解它。 WCF是.NET中Web服务和其他面向服务的开发的现在和未来，因此他们非常有动力倾听您并解决您的痛点。可以通过Connect直接与他们联系，也可以在此处提出问题（请使用WCF标记），很多人会帮助您。
答案 4 :(得分：2)
从程序员的角度使用WCF的最大优势：将公开服务（操作，合同等）的定义与协议的特定细节分开，这与ASMX不同，在ASMX中，您直接在代码中将类作为Web服务公开使用属性。使用我的一个真实示例：我们能够轻松地在Web服务和命名管道之间切换传输协议，无论是否更适合部署和性能需求，而无需更改代码行。
答案 5 :(得分：1)
为了解决应用程序配置的维护噩梦问题，存在一些标准，如UDDI或WS-Discovery，WS-Discovery将由.NET 4.0中的WCF支持。
保持配置 代码中的接口而不是移动 明确定义接口 XML，可以发布和 被几乎任何东西消耗。我知道 可以从汇编中导出XML， 但它充满了垃圾和确定 代码生成器阻塞它。
你能更明确吗？我想你在谈论在代码中配置的服务行为。 您可以轻松编写行为扩展代码来配置您在配置文件中所说的内容而不是代码但是我认为如果微软没有这样做，那么有充分的理由。 例如，具有此行为的服务：
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)]
实现知道实例不在多个线程之间共享，因此它的开发方式与：
不同[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
在这种情况下，服务实现应该关注concurency问题。 该实现与ServiceBehavior属性相结合，因此在XML文件中移动此行为不是一个好主意。
如果您可以将InstanceContextMode.PerCall服务更改为配置文件中的InstanceContextMode.Single服务，该怎么办？你打破了申请！
答案 6 :(得分：1)
WCF旨在用于SOA方法。专业地使用它是一场噩梦。我使用WCF作为工具和地狱，数百个配置和隐藏提示提供了SOA解决方案！我过去使用旧式Web服务和远程处理的分布式解决方案更加稳定。我花了几天时间为错误解决“基础连接已关闭：发生了意外错误”，这对于同一合同中的4个方法中的一个方法没有任何意义。我非常失望。它让我回过头来.net首次推出了许多承诺，当我们接手时，地狱，日志问题出现了！
答案 7 :(得分：0)
看看你如何提及XML和SQL，你正在使用WCF来构建一个Web应用程序或一个实际的Web服务（Web上的服务，而不仅仅是SOAP交换）。
它有助于将WCF视为.NET Remoting（或DCOM，CORBA等）的替代品，它也恰好支持Web服务作为传输之一。在程序集中声明的接口，代理的行为，某些配置选项以及从Web应用程序的角度看起来不自然和复杂的框架的其他方面 - 实际上开箱即用的DCOM风格的分布式对象系统。
回答这个问题：不，你没有遗漏任何东西，并且使用WCF进行Web应用程序很复杂，因为WCF不是构建Web应用程序的框架。可能这样的框架可以构建在它之上，但我不愿意看到WCF本身改变为进入web领域。