MarshalByRefObject 的创造性使用

Question

我一直在敲着头试图弄清楚一些事情。因此，我正在寻找建议和研究材料（通过链接）。这是场景：

我们有一个库（例如 CommonLib），其中包含其他几个应用程序（例如 AppA、AppB、AppC 等）所需的资源。现在，当前的工作方式是 AppA 实例，检查特定端口是否可用。如果不是，那么它会启动 CommonLib（“嘿，醒来”）并启动服务。然后 AppA 很高兴，然后我们就出发了。

现在，我已经对 Remoting.Channels 进行了大量研究，并且得出的结论是，我正在启动一个基于被视为“传统”技术的应用程序。嗯...我不喜欢这样。老实说，WCF 的开销比我们需要的要多得多，而且在 Mono 中还没有完全实现。我们的目标是多平台兼容性（Windows、Mono、Linux），因此我们正在研究所有选项。

远程处理的想法首先是因为我们希望 CommonLib 成为一个有保证的单一实例（据我所知，单例几乎只能保证是给定 AppDomain 内的单例 - 如果我有疑问，请随时纠正我）错了）。不管怎样，我意识到了远程处理的力量，并决定开始一些实验性的实现。我对 MarshalByRefObject 的初次使用取得了成功。但是，我担心这项遗留技术的继续实施。

因此，有了这一切...我正在考虑如何实现 CommonLib（作为主机应用程序），并且在不进行远程处理的情况下，通过 Stream、标准 TCP 套接字或其他方式实现 MarshalByRefObject。我的想法是，不要实例化 AppA 来运行 CommonLib，只需将 CommonLib 实现为基本应用程序即可。然后，您选择要在 CommonLib 中实例化的应用程序（实际上只是“托管”.dll）。然后，CommonLib 会将该 .dll 以及托管应用程序使用的任何自定义控件加载到 CommonLib 框架中。除了这个想法之外，我（暂时）放弃了 CommonLib 必须是真正的单例的要求。

所以...这就是我们场景的细节。再说一遍，我的问题实际上分为两部分：(a) 我应该研究哪些技术，以及 (b) 我是否需要关注远程技术的遗留状态？

任何其他建议、评论或问题都非常受欢迎。

更新1：我从 这个片段. 。这将允许我加载包含已安装的应用程序（或插件）列表的文件（或脚本）。我可以将此文件创建为 Xml 或二进制格式。安装新应用程序时，可以添加文件和路径。嗯...我不一定需要使用 MarshalByRefObject。

Answer 1

虽然 WCF 可能不是 完整 在Mono中，Mono 2.6提供了silverlight/moonlight所需的一切，因此基于WCF的实现应该是完全可行的。只要您不尝试任何奇特的东西（不同的传输、检查器等），它应该足以提供在 windows / mono / 等之间可靠的 RPC 堆栈。

WCF 和远程处理之间的主要区别在于 用法 - 远程处理基于大量假装位于不同端的对象，而 WCF 则基于服务；重点是你应该围绕离散方法进行交互（而不是访问属性等）——这还有一个优点，可以在跨越边界时帮助使其变得明确。

另一种选择是编写一个非常基本的套接字服务器；非常轻量级，您可以使用像 protobuf-net 这样的东西来提供便携式（跨平台）序列化器实现（您不应该真正信任 BinaryFormatter 两者之间——它是……片状）。

简而言之 - 我不会围绕 MarshalByRefObject 根本不;我会编写一个服务层，例如：

interface IMyService {
    void Method1();
    int Method2(string s);
}

并将这些细节从调用者那里抽象出来。如果您最终使用 WCF，那就是 全部 你需要;对于现有的远程处理支持，我会写一个 IMyService 实施 封装 （私下）整个 MarshalByRefObject 故事。如果我写了一个套接字服务器，也是如此。

Answer 2

我不确定 .NET Remoting 是否已被 WCF 淘汰。我认为它们的用例有些不同；WCF（故意）没有“通过引用编组”的概念，因为它是为分布式和（相对）松散耦合的应用程序设计的，这些应用程序可能需要避免由于延迟等原因而导致的繁琐协议。如果您的组件自然紧密耦合，则延迟会很低，但性能需要很高，保留丰富的 .NET 类型很重要，等等。那么远程处理可能仍然是一个不错的选择。不管怎样，我不担心成为“遗留”技术，至少在 Windows/.NET 上的“遗留”技术如果得到相当多的使用，它们会有办法保留相当长的一段时间。最新 (4.0) 版本的 .NET 中仍然存在远程处理。

这一切并不意味着远程处理必然 是 最适合您的情况...