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