之前的文章有提到 edge 和 nodejs 交互，通过node的模块为C# 提供一些扩展，这个还是比較方便。
这里说下为什么要使用js。
1.SharpKit是一个用于在编译时将C#语言转换为JavaScript的工具。
从试用上来说还是比較强大的，基本上支持大部分语法。
2.c# 尽管是比較强大的，可是在一些方面还是比較薄弱的，并且在一些平台上还有些限制。
比方 ios 平台上unity3d 不能做到热更新。当然大部分时间都是用不到热更新的。
可是假设想用的时候能用还是不错的。
要解决的问题？
怎样打通C#和JS间的桥梁，已经有多个实现。比方上文提到的edge就是一个解决方式。
或者jint，Jurassic，ironjs这种动态语言，或许性能上没v8强大，可是满足日用基本上也是足够了。
基于传统的值之间的传递。须要对模块进行严格的分割，在开发中须要预留接口。或者进行专门的模块设计，会导致开发中的进度拖慢，或者导致开发中的部分问题。
怎样能达到无缝接入和侵入是如今所须要考虑的问题。
首先，我们多多少少都有一些已经存在的模块，旧有的模块可能须要一些底层的类库使用继承或者接口达到一些设计上的便利，可是跨语言/引擎的继承基本上是不可实现的。
然后。假设在开发中就须要考虑js的接入，那么会对开发者能力带来考验。须要一个即会js又会c#的势必带来更高的开发难度，这样是我们所不愿意看到的。
那么，我们期望是什么？
我们期望在开发完毕后，以最小的代价进行代码模块的切换，从公布手段上达到无缝切换引擎的目的。无论是nodejs 还是 dlr类引擎。
然后。为什么我们可能须要这种切换。除了上文说到的热更新，那么能够跟上V8的大潮不得不说是一件比較开心的事情，nodejs。html5，等等。都是在可预想的范围内的。
最后。问题来了，为什么是c#。而不是js？
这得不得不从强大的VS说起，一个强大的IDE是效率开发的根本，而c#有着较低的入门门槛，在mono的大前提下，理论上全部平台移植已经都不是问题，可是js似乎更轻量一点，由于全部的平台上都有浏览器，旧有无所不在的js引擎。而各家不断竞争的js引擎大赛也是促成js遍地开花的原因之中的一个。
设想：
1.首先，我们要解决对象继承问题，有的人说oo已死，这是仁者见仁。智者见智的事情，这里暂不讨论，我们说一下怎样模拟继承，继承的好兄弟有另外一个。叫 组合，我们从js层创建 一个基础对象，然后里面包括一个 c# 的object。然后通过反射把全部的方法通过反射映射到 js 对象上，我们就拥有了第一个完毕继承的伪对象。从使用上并没有什么问题。仅仅有经过类型推断和类型转换的时候我们须要重写一些机制。流程大约是这种：
c#/js调用某个对象的方法-》找到js方法-》调用c#内部对象方法-》返回结果
c#/js调用某个对象的方法-》找到js方法-》返回结果
2.接口。因为接口必须创建一个实现接口的对象，那么在无法动态创建类的平台上。我们就没有办法了。所以我们必须创建一个通用接口。临时叫 Js通用接口，（能够由代码生成器默认生成）内部就是一个空的实现，有个入口跳转到js，流程大概是这样：
c# -》接口-》通用接口-》调用js中的方法-》返回结果
从这种一种方式。我们实现了js实现c#接口的曲线救国方式。
3.重载。类似接口。必须通过一个代理模式实现。上面继承模式说明js类中必须包括一个c#的底层类。那么我们将这个底层类变成所谓的代理类。代理类中的方法调用指向的是js中的方法。因为代理类是继承与c#类的。那么他的实例化应该是 c#代理类（js类），那么我们的流程大概是这样：
c#-》方法-》代理类方法-》js对象方法（假设无重载）-》调用c#内部对象方法-》返回结果
从以上3点设想能够看出，我们须要提供一个代理类。也就是须要导出的接口的代理类，或者须要继承对象的代理类。然后通过js《-》c# 互通达到透明訪问的目的。
