创造性地使用MarshalByRefObject

Question

我一直在绞尽脑汁想弄清楚一些事情。因此，我正在寻找建议和研究材料(通过链接)。以下是场景：

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

现在，我对Remoting.Channels做了很多研究，我得出的结论是，我正在启动一个基于一种被认为是“遗留”技术的应用程序。嗯……我不喜欢这样。老实说，WCF的开销比我们需要的要多得多，而且还没有完全在Mono中实现。我们的目标是多平台兼容性(Windows，Mono，Linux)，所以我们正在研究所有的选择。

远程处理的想法最初是因为我们希望CommonLib是一个有保证的单实例(据我所知，在给定的AppDomain中，单例几乎只能保证是一个单例-如果我错了，请随时纠正我的错误)。无论如何，我意识到了远程处理的强大功能，并决定开始一些实验实现。我已经成功地首次使用了MarshalByRefObject。但是，我担心这项遗留技术的继续实施。

所以，有了这一切……我正在考虑如何实现CommonLib (作为主机应用程序)，并且在不进行远程处理的情况下，通过流、标准TCP套接字或其他方式实现MarshalByRefObject。我的想法是，与其通过实例化AppA来运行CommonLib，不如将CommonLib作为基础应用来实现。然后，选择要在CommonLib中实例化的应用程序(实际上只是一个“托管”的.dll)。然后，CommonLib会将该.dll连同托管应用程序使用的任何自定义控件一起加载到CommonLib框架中。有了这个想法，我放弃了(目前) CommonLib必须是真正的单例的要求。

So...that是我们场景中的一个细节。同样，我的问题实际上是两个部分：(a)我应该研究什么技术，以及(b)我是否需要关注远程处理技术的遗留状态？

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

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

Answer 1

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

WCF和remoting之间的关键区别在于使用-远程处理基于大量假装在不同端的对象，而WCF基于服务；要点是您应该基于离散方法(而不是访问属性等)进行交互-这也有帮助在跨越边界时使其显式。

另一种选择是编写一个非常基本的套接字服务器；非常轻量级，您可以使用protobuf-net之类的东西来提供可移植(跨平台)的串行器实现(您不应该真正信任两者之间的BinaryFormatter -它是...flakey)。

简而言之，我根本不会围绕MarshalByRefObject构建；我会编写一个服务层，类似于：

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

并将这些细节从调用者那里抽象出来。如果您最终使用的是WCF，那么这就是您所需要的；对于现有的远程处理支持，我将编写一个封装(私下)整个MarshalByRefObject故事的IMyService实现。如果我写了一个套接字服务器，情况也是如此。

Answer 2

我不确定WCF是否会被.NET淘汰。我认为它们有一些不同的用例；WCF (故意)没有“按引用封送”的概念，因为它是为分布式和(相对)松散耦合的应用程序设计的，这些应用程序可能需要避免由于延迟等原因而导致的闲聊协议。如果你的组件自然是紧密耦合的，那么延迟将会很低，但性能需要很高，保留丰富的.NET类型很重要，等等，那么远程处理可能仍然是一个很好的选择。无论如何，我不会担心成为“遗留”，“遗留”技术至少在Windows/.NET上有一种方法可以在相当长的一段时间内保留下来，如果它们得到了相当多的使用。远程处理仍然存在于最新(4.0)版本的.NET中。

这并不意味着远程处理一定是最适合您的情况的声明……