我有一个Web应用程序，它使用.NET Remoting将长时间运行的请求传递到另一台计算机上的Windows服务。有人告诉我，.NET Remoting是一种过时的技术，它不应再被使用了。
我应该使用WCF重写服务，还是保持原样？如果我重写它，当微软用其他东西替换WCF时，我是否还要重写它？
注意：这不是一个修辞问题。微软已经至少改变了三次远程故事。 （DCOM，.NET Remoting，WCF，？...）
答案 0 :(得分：9)
鉴于WCF和.NET Remoting不是很容易互换（.NET Remoting基于远程对象，而WCF更多的是面向文档的消息传递），我不会麻烦只是将代码重写为WCF因为.NET Remoting不再被认为是热门的。当然，您的实际情况可能会有很大差异。
如果.NET Remoting适合您并且不需要更改，请保留它。在某些时候，您可能不得不考虑切换到基于WCF的技术来支持更多样化的客户 - 这些过渡似乎很常见 - 但直到那一天到来，保持简单。但是，我会从一开始就在WCF上编写新的应用程序，主要是为了鼓励自己保持在具有SOA意识的文档通信模型中。
答案 1 :(得分：5)
我认为我们应该清楚Remoting的状态。它很可能永远不会得到改善。它很可能会大大减少错误数量。它可能会达到只有业务关键错误或安全关键错误才能得到解决的程度。
您可能还想考虑微软显然不认为有必要采用“远程处理”解决方案。也就是说，服务器中有对象，完成状态和远程机器的解决方案可以通过代理实现通过网络实际转到特定对象的方法调用。
请注意，Remoting的大量技术是WCF的一部分。通道和消息堆栈的可扩展性;可配置性的程度;所有这些都是WCF的一部分。
坦率地说，我认为您没有理由更改现有代码。但是，我建议您花点时间到达组织中的某个点，如果您使用Remoting开始一个新项目，那么您可以放心使用WCF。
最后，您觉得WCF无法容纳Remoting的任何部分吗？我的意思是，除了在WCF中分离行为和数据这一事实。
P.S。在我看来：
答案 2 :(得分：1)
WCF只是包含远程处理的几种不同方式的全方位抽象。实际上，没有性能保证，在某些情况下，远程处理比WCF快得多。
如果您按照.NET远程指导实现了项目。然后迁移不应该很简单。
我个人的建议是保留原样，除非您可以根据业务需求证明迁移的合理性。
答案 3 :(得分：1)
.NET Remoting并没有过时。要成为过时的技术应该有继承者，这不是.NET Remoting的情况。 WCF和.NET Remoting实际上做了不同的事情。当.NET Remoting是对象分发解决方案时，WCF是消息传递解决方案（它是ASPX的后继者）。
所以我的建议是不要把你的实现更新到WCF，只需使用.NET Remoting（免责声明，我曾经使用.NET Remoting作为消息传递解决方案，现在我的默认选择当然是WCF）。
答案 4 :(得分：1)
我会说，除非您当前的解决方案不符合特定需求，否则不需要重写它。是的，.NET Remoting将不再是先进的bna din理论已被WCF取代但我的感觉是，如果它不能解决为什么修复它？
PS。 WCF不是纯粹的消息传递解决方案，因为上面的一些人正在努力实现它。 MS已将其定位为应用程序和应用程序组件之间所有通信的通用方式。它集成了各种技术，如MSMQ，.NET Remoting，Web Services等。
答案 5 :(得分：-1)
如果你想要真正的长寿，你应该建立自己的远程技术，原因有两个。首先，将自己与Microsoft技术紧密联系起来并不是一个好主意。正如你所说，他们过快地淘汰了东西。其次，根据您自己的需求，它应该优于您的应用程序的任何远程处理框架。
我在基准测试中击败了10％的SOAP远程处理，但由于某些原因我不知道，10％的基准调整为90％的场地增益。