.Net 與 Javascript 混合編程系列

     以前的文章有提到 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# 互通達到透明訪問的目的。