之前的文章有提到 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# 互通达到透明访问的目的。