JointCode.Shuttle 是一个用于进程内 AppDomain 间通讯的服务架构(不支持跨进程),它旨在取代运行时库提供的 MarshalByrefObject 的功能。html
1. 使用场景
git
在 .net / mono 开发中,通常不太须要建立新的 AppDomain,但在一些 特定状况 下,也许咱们须要使用一个新的 AppDomain,并在其中执行一些操做。github
当代码跨越 AppDomain 边界访问另外一个 AppDomain 时,便产生了跨 AppDomain 通讯。这时候,您能够考虑使用 JointCode.Shuttle。架构
2. 传统跨 AppDomain 通讯方式的问题框架
通常来讲,在进行跨 AppDomain 调用时,大部分人使用运行时库默认提供的、基于 MarshalByrefObject 类继承的通讯机制。这种方式最简单,只要让须要跨 AppDomain 操做的类继承 MarshalByrefObject 便可,实现起来很方便。例如:ide
1 namespace JoitCode.Shuttle.SimpleSample 2 { 3 public class MyService : MarshalByRefObject 4 { 5 public void Do() { } 6 } 7 8 class Program 9 { 10 static void Main(string[] args) 11 { 12 // 在默认 AppDomain 中建立一个子 AppDomain 13 var serviceDomain = AppDomain.CreateDomain("ServiceDomain", null, null); 14 15 var myService = (MyService)serviceDomain.CreateInstanceAndUnwrap 16 (typeof(MyService).Assembly.FullName, 17 "JoitCode.Shuttle.SimpleSample.MyService"); 18 19 myService.Do(); 20 21 Console.Read(); 22 } 23 } 24 }
简单是简单,但这种方式也有一些局限性。有什么局限性呢?性能
除了 MarshalByrefObject 以外,可能还有 remoting、wcf 甚至于消息队列等等跨进程的方式也能够实现跨 AppDomain 通讯(做者本身没尝试过)。这些方式或多或少消除了上述那些限制,然而咱们也能想象获得,原本是进程内通讯的事情,如今弄成进程间通讯,凭空增长许多开销,那么它们的性能必定比 MarshalByrefObject 更低,并且学习成本也会更高,实现起来也更复杂。学习
3. JointCode.Shuttle 的特色测试
与 MarshalByrefObject 相比,JointCode.Shuttle 除了具有相同的跨 AppDomain 通讯的功能以外,还有本身的一些特色:spa
4. 将来计划
JointCode.Shuttle 是一个很是新颖的框架,功能还不是很完备。尽管做者将会在将来继续完善现有功能,并推出更多新的功能,但目前仍是存在一些不足,主要包括:
5. 如何使用 JointCode.Shuttle
若是您对 JointCode.Shuttle 有兴趣,请移步前往 这里,咱们提供了一个简单的示例来讲明如何使用这个框架。