将应用程序迁移到WCF有什么好处,而不是继续使用.NET Remoting？

Question

好吧,所以我在StackOverflow上询问了几个关于.NET Remoting的问题,并且总是至少有一个人不得不插手,".NET Remoting已被弃用,而是使用WCF." 我知道它已被弃用,并且无法保证将来支持新版本的.NET Framework.但是我们想要转移到WCF还有哪些其他好的理由呢？我已经看到了.NET Remoting的一些主要的小麻烦,然而,这还不足以改变那些坚定地相信"如果它没有破坏,不解决它"的权力.此时,态度将改变的唯一原因是.NET Remoting是否已从.NET Framework的未来版本中删除,那么谁知道这将会持续多久？

有没有人知道为什么WCF比.NET Remoting"更好",或者为什么Remoting不如WCF？每种技术的优缺点是什么？您是否可以使用WCF进行其他操作而不使用Remoting？

我的意思是,如果我能说服他们让我们将软件迁移到WCF只是为了允许在客户端设置可配置的TcpChannel超时(这似乎已经被打破了一段时间,无论采取什么步骤,那将是很棒的或者我尝试排除故障),当发生这种情况时,它会使我们的软件看起来像绝对的东西.

在此先感谢您帮助阐明这一点.

Answer 1

抛弃远程有很多理由; 一些可能包括:

• 缺乏运输灵活性
• 版本要求是巨大的痛苦
• 平台依赖(没有明显的跨平台使用机会)
• 没有机会从不断增长的移动市场中使用
• 缺乏未来的发展:你想要添加的任何功能 - 它不会

但是,我不同意WCF是自动替换; WCF本身是一个非常通用的工具,但可能非常复杂,并且有自己的限制.我自己没有使用它,但我看到很多服务栈的赞誉,主要是用户将其描述为"WCF完成正确",即WCF的好位,没有痛点.但是,还有很多其他选择.但是,关于Service Stack的一个好处是它可以很快地迭代,如果它缺少你想要的东西,你可以改变它.

Answer 2

.NET Remoting现在是一种传统技术,引自MSDN:

本主题特定于为保持与现有应用程序向后兼容而保留的旧技术,不建议用于新开发.现在应该使用Windows Communication Foundation(WCF)开发分布式应用程序.

这是在2007年完成的WCF和.NET Remoting之间的性能比较:http://msdn.microsoft.com/en-us/library/bb310550.aspx

总结结果,WCF比ASP.NET Web服务快25%-50%,比.NET Remoting快约25%.

所以我认为速度是放弃.NET Remoting的一个很好的理由.