由一次WCF專案的需求擴充套件想到的

這個小專案或者說是小功能大約一年以前開發的。現在寫這篇文章只是為了共享這個思路使有同樣需求的人少走彎路。公司其它人員開發了一個適用於pc客戶端呼叫的wcf服務。由於公司新增了android與ios客戶端的開發。所以這些程式碼也需要訪問這個wcf服務，之前讓許多人做別人不是android訪問不到就是對原有wcf改動太大(還有一個 Zhou某某，平時吹的挺牛B,弄了好幾天也沒弄好)。後來領導把這個任務交給了我。接到這個任務後，我分析了下現有的程式碼，由於android與javascript，c#呼叫訪問的資源是一樣的，只不過是訪問方式不同而已。所以最好還是不要動現有的wcf，於是我就另啟了一個wcf服務，專門用來給android訪問。而我的服務接收到andoird的請求後，再訪問原先的wcf服務。這樣做的好處是：
　　一，可以將程式碼的改動量做到最小，基本上原先的wcf服務不用動，只要改動時，把釋出後的dll檔案替換掉就行。
　　二，得用反射分析Wcf釋出的dll檔案（這其中用到了部分的編譯原理知識）。
　　現在簡單描述下這個專案的執行原理：
　　其實就是讓android訪問wcf時，將要呼叫的方法名及引數，用一個統一的json物件包裝起來。首先根據呼叫的方法名來動態分析dll檔案，查詢是否有此方法，如果沒有則返回錯誤。如果有，則利用反射動態分析些方法，主要是引數及返回值，然後根據獲取到的引數及返回值資訊來將android傳入的json物件一一進行型別轉換，然後呼叫此方法，並將返回值轉換成json,返回給andriod或ios(其實javascript訪問也是這個原理，只不過是wcf配置稍有不同而已)。
這個小專案或者說小功能做好後，執行很穩定。可惜後來由於要寫公司的解析程式及地圖資訊服務，領導把這個專案讓我交給別人了（可能領導到現在還不知道這個方法的原理，也許以後說起時就是別人的功勞了）。