【发布时间】：2012-08-21 08:53:35
【问题描述】：
我有一个应用程序，它需要有多个应用程序域来隔离潜在的不安全模块，并为非线程安全代码提供一定程度的隔离。每个模块都实现了一个通用接口，但也包括长期存在的方法调用（分钟）。
在遥远的过去，当我做类似的事情时，我使用MarshalByRefObject，但我现在read that WCF 是跨 AppDomain 边界通信的首选机制。
由于我想要多个应用程序域并且每个请求都可能是长期存在的，因此我发现了几个问题：
- 我明确地只需要一个线程在给定时间执行“工作”代码（因此 WCF 为每个请求实例化新主机类的默认方法是一个问题）
- 如何管理应用程序域列表/适当的端点以进行调用（如何通知每个 AD 使用哪个端点/它应如何报告它随机选择的端点）
我最初计划对 AppDomain 进行异步调用，并在内部使用某种形式的排队系统，使我能够监控/检索结果，但考虑到使用 WCF 和重写足以控制服务实例化的麻烦主机对象（以允许对同一对象进行后续调用），我开始怀疑是否应该使所有调用阻塞并允许父进程处理所有线程问题。当然，那么我还需要确保对给定应用程序域的待处理呼叫不超过 1 个，并在父进程中执行排队。
有没有人有过类似场景的经验/关于良好架构的建议/不错的文章的链接？
【问题讨论】：
-
老实说，对于您想要的 AppDomain 的紧密耦合控制，我认为 WCF 不是一个好的解决方案。 WCF 中固有的基本架构设计是松散耦合、面向服务和基于远程过程调用的。我相信 WCF 为您的预期设计提供了错误的抽象级别。只是我的 2 位 :)
-
@SixtoSaez 谢谢 - 我不同意你的观点，因为 WCF 模型似乎不太适合，因此我提出了很多问题。我可能会坚持一些
MarshalByRefObject，看看情况如何。顺便说一句，如果您想发布作为答案，如果我没有更好的选择，我会接受。
标签： .net wcf remoting appdomain .net-4.5