传统“通信”的使用 .NET Framework 中的类

Question

我有一个 Web 应用程序，它使用 .NET Remoting 将长时间运行的请求传递到另一台计算机上的 Windows 服务。 有人告诉我 .NET Remoting 是一种过时的技术，不应再使用它。

我应该使用 WCF 重写服务，还是保持原样？ 如果我重写它，当微软用其他东西取代WCF时，我是否还得重新重写它？

注意：这不是一个反问句。 微软已经至少三次改变了它的远程故事。 （DCOM、.NET 远程处理、WCF、？...）

Answer 1

鉴于 WCF 和 .NET Remoting 不太容易互换（.NET Remoting 基于远程对象，而 WCF 更多的是面向文档的消息传递），我不会仅仅因为 .NET 就将代码重写为 WCF 的麻烦远程处理不再被视为热门。 当然，您的实际情况可能会有很大差异。

如果 .NET Remoting 适合您并且不需要更改任何内容，请保留它。 在某些时候，您可能必须考虑切换到基于 WCF 的技术来支持更多样化的客户端 - 这种转变现在似乎很常见 - 但在那一天到来之前，请保持简单。 然而，我会从一开始就在 WCF 上编写新的应用程序，主要是为了鼓励自己保持 SOA 思维的文档通信模型。

Answer 2

我想我们应该清楚Remoting的地位。 它很可能永远不会得到改善。 修复的错误数量很可能会大幅减少。 它可能会达到只修复业务关键错误或安全关键错误的程度。

您可能还需要考虑到 Microsoft 显然并不认为“远程”解决方案是必要的。 也就是说，解决方案中服务器中有一个具有状态的对象，并且远程计算机可以进行方法调用，这些方法调用实际上通过代理跨网络到达该特定对象。

请注意，Remoting 的大部分技术都是 WCF 的一部分。 通道和消息栈的可扩展性； 可配置性的程度； 所有这些都是 WCF 的一部分。

坦率地说，我认为您没有理由更改现有代码。 不过，我建议您花一些时间在您的组织中达到这样的程度：如果您想使用远程处理启动一个新项目，那么您可以轻松地使用 WCF。

最后，Remoting 是否有您认为 WCF 无法适应的部分？ 我的意思是，除了 WCF 中行为和数据已分离这一事实之外。

---

PS 在我看来：

• WSE 已经过时了。 除非您别无选择，否则不要使用它。 尽快更换。
• ASMX 现在被公开承认为“遗留技术”。 请参阅 ASMX Web 服务是一项“传统技术”，并发表评论如果你喜欢的话。
• 在我看来，远程处理与 ASMX 的地位几乎相同，因为它的大部分或全部功能已被 WCF 取代。

Answer 3

WCF 只是几种不同方式组合在一起的包罗万象的抽象，其中包括远程处理。 没有性能保证，事实上，在某些情况下，远程处理比 WCF 快得多。

如果您按照 .NET 远程处理指南实施了您的项目。 那么迁移应该不会很简单。

我个人的建议是保持原样，除非您可以根据业务需求证明迁移的合理性。

Answer 4

我想说，除非您当前的解决方案不能满足特定需求，否则不需要重写它。 确实，.NET Remoting 将不再先进，因为理论上已被 WCF 取代，但我的感觉是，如果它没有损坏，为什么要修复它呢？

附： WCF 并不像上面一些人所说的那样是一个纯粹的消息传递解决方案。 MS 将其定位为应用程序和应用程序组件之间所有通信的通用方式。 它是多种技术的整合，例如 MSMQ、.NET Remoting、Web 服务等。

Answer 5

.NET Remoting 并没有过时。 成为过时的技术应该有继任者，但 .NET Remoting 的情况并非如此。 WCF 和.NET Remoting 实际上是做不同的事情。 当 .NET Remoting 是对象分发解决方案时，WCF 是消息传递解决方案（并且是 ASPX 的后继者）。

因此，我的建议是不必费心将实现更新为 WCF，只需使用 .NET Remoting（免责声明，我曾经使用 .NET Remoting 作为消息传递解决方案，现在我的默认选择当然是 WCF）。

Answer 6

如果您想要真正的长寿，您应该构建自己的远程技术，原因有两个。 首先，将自己与 Microsoft 技术联系得太紧密并不是一个好主意。 正如你所说，他们很快就过时了。 其次，根据您自己的需求进行调整，它应该优于您的应用程序的任何远程处理框架。

我在基准测试中击败了 SOAP 远程处理 10%，但由于某种我不知道的原因，10% 的基准测试调整为 90% 的现场增益。