我对WCF有什么看法？

我在MS技术方面的开发时间比我在此阶段要记住的时间长.当.NET到达现场时,我认为它们触及了头部,每次迭代和版本我认为他们的技术越来越强大,并期待每次发布.

但是,由于去年必须与WCF合作,我必须说我发现这项技术非常难以使用和理解.最初它非常吸引人但是当你开始深入了解它时,配置是一场噩梦,必须覆盖消息大小的行为,消息中包含的对象数量,安全模型的复杂性,出现故障时处理代理以及最终回到定义代码而不是XML中的接口.

它只是没有开箱即用,我认为应该.我们在测试自己时或者当我们的产品在现场时,我们发现了上述所有问题.

我确实理解这一切背后的基本原理,但肯定他们可以提出更简单的实现机制.

我想我要问的是,

我是以错误的方式看待WCF吗？

它对替代品有什么优势？

在什么情况下我应该选择使用WCF？

OK伙计们,对于延迟回复感到抱歉,工作确实有一个令人讨厌的习惯,有时会妨碍:)

一些说明我对WCF的主要描述我想到了以下几个方面虽然它开箱即用,但你的左侧有一些重大的惊喜.如上所述,基本事物在被覆盖之前是受限制的

字符串的大小可以通过不能超过8K

可以在单个消息中传递的对象数受到限制

代理不会自动从故障中恢复

配置的数量虽然有好处,但要了解所有内容以及使用什么以及在哪种情况下难以理解.特别是在具有不同安全要求的现场部署软件时等.在谈论配置时,我们不得不在后端数据库中隐藏我们的许多内容,因为现场的安全和网络人员试图在不理解的情况下更改配置文件中的内容它.

保持接口的配置在代码中,而不是移动到XML中显式定义的接口,几乎任何东西都可以发布和使用它们.我知道我们可以从程序集中导出XML,但它充满了垃圾,并且某些代码生成器会阻塞它.

我知道世界在继续前进,我已经多次(最近22年来我一直在开发)并且正在积极地使用WCF,所以不要误解我的意思,我明白它的用途是什么它在哪里.

我认为应该有更简单的配置/部署选项,更容易的设置和更好的配置管理(SQL配置提供程序可能,而不仅仅是web.config/app.config文件).

1> Jonathan All..：

---

我现在一直使用WCF,我分享你的痛苦.看起来它过于严格,但我们将长期坚持使用它,所以我正在努力学习它.

我确信一件事,XML很糟糕.我只有使用XML来控制它的问题,并且已经切换到通过代码处理所有内容.

---

这对那些只在服务器上提供记事本的生产支持人员没有帮助.

---

你是什​​么意思没有XML？XML仍然在混乱我的app.config文件与无用的垃圾.

---

您是否尝试过使用WCF配置工具(Windows SDK目录中的SvcConfigEditor)？没有XML.

2> Cheeso..：

---

您列出的问题包括:

---

字符串的大小可以通过不能超过8K

可以在单个消息中传递的对象数受到限制

代理不会自动从故障中恢复

配置的数量虽然有好处,但要了解所有内容以及使用什么以及在哪种情况下难以理解.特别是在具有不同安全要求的现场部署软件时等.在谈论配置时,我们不得不在后端数据库中隐藏我们的许多内容,因为现场的安全和网络人员试图在不理解的情况下更改配置文件中的内容它.

保持接口的配置在代码中,而不是移动到XML中显式定义的接口,几乎任何东西都可以发布和使用它们.我知道我们可以从程序集中导出XML,但它充满了垃圾,并且某些代码生成器会阻塞它.

---

这是我的看法:

(1)解决了客户对ASMX的有效关注.它太开放了,无法轻易控制它.如果您知道要去哪里,可以轻松解除8k限制.我想你可以把它算作一个惊喜,但它更像是一次性的事情.一旦你了解它,你可以解除它,如果你愿意,可以永远完成它.

(2)也是可配置的.

(3)是已知的,但有解决这个问题的样板方法.该StockTrader代码例如,演示了一个成熟的模式.您可以在自己的应用中重复使用该代码.不确定这是否在WCF for .NET 4.0中得到修复.我知道这是一个公开的请求.

(4)配置是野兽.这是很多人关注的问题.这里的问题是WCF非常灵活,所有这些灵活性的配置都是通过xml文件公开的.它可能是压倒性的.一种似乎有用的方法是在需要的时候将它放在小口中.

(5)我不明白.

3> marr75..：

---

我非常喜欢基于WCF的ASP.NET MVC和Web API.如果我不得不将WCF总结给刚刚介绍它的开发人员,我会说,"WCF是一个很好的尝试来取代过度设计的Java EE风格的RPC开发." 不幸的是,许多决策要求您成为配置低级别,不重要的项目(消息大小,超时,不感兴趣的协议元素等)的专家,同时抽象绝对关键的部分(URL设计,参数序列化,响应序列化等). ).我知道使用WCF与Web API的团队之间的生产力和恶化程度的差异是白天和黑夜.

要清理一下:我一直很讨厌.NET Remoting的核心概念.我觉得开发人员需要彻底了解他们的应用程序的资源结构以及这些资源是如何序列化的.此外,在需要扩展的读取繁重的应用程序中使用"POST"动词进行简单的数据检索是令人担忧的.

4> John Saunder..：

---

澄清之后,我会解决其余的问题.与此同时,我可以解决您何时应该选择使用WCF的问题:始终.

WCF是旧ASMX技术的替代品,包括WSE.它也是.NET Remoting的替代品.它是.NET中高级通信功能基于可预见的未来的唯一技术.

例如,考虑Windows Azure."云计算"这一新概念在WCF中涵盖其通信方面并非不可避免.然而,WCF足够灵活,可以扩展到覆盖这些情况,代码变化很小.

如果您遇到WCF问题,那么您最好确保Microsoft了解它.WCF是.NET中Web服务和其他面向服务的开发的现在和未来,因此他们非常有动力倾听您并解决您的痛点.要么通过Connect直接联系他们,要么在这里提问SO(请用WCF标记),很多人会帮助你.

---

"为什么要进行投票？这是不准确的？" - >"当你应该选择使用WCF:总是" - 所以,简而言之,是的.

---

企业的需求不一定取决于MS认为的"遗产".我们开发人员喜欢忘记因为我们喜欢玩新玩具.当然你可以自由地反对意见,但不要相信你或MS已经说服每个人只是为了转换而切换.坦率地说,WCF过渡的故事在各个方面都不那么引人注目.但是对于远程处理,WCF是一个巨大的进步.但是对于快速而肮脏的Intranet Web服务,您可能会在web.config中丢失太多宝贵时间.

---

我已经学会了它,并且已经开发了相当数量的 - 但我并不急于修复我们旧的和工作的.ASMX服务.老实说,从ASP.NET MVC控制器构建RESTful`JsonResult`需要一小部分开发时间,因此我建议尽可能一起跳过正式的Web服务.