添加wcf服務引用時，vs.net本來就會幫我們在app.config/web.config裡生成各種配置，這沒啥好研究的，但本文談到的配置并不是這個。先看下面的圖：
通常，如果采用.NET的WCF技術來架構SOA風格的應用，我們會把項目做一些基本的分層，如上圖：
01. contract層：通常定義服務的接口(即服務契約ServiceContract，指明該服務提供了哪些方法可供外部調用)、以及接口方法中傳輸的Model定義（即：資料契約DataContract，指明方法中的對象參數的Class定義）
02. implementation層：即服務接口的實作
03. host層：wcf最終需要一個宿主環境，如果是web應用，最簡單的辦法莫過于直接寄宿在IIS上
04. client層：即服務的消費方，如果是b/s應用，通常就是一個web application
實際部署時，一般将wcf服務層和client層分開部署，如下圖：
如果并發數随着業務的增長而增長，不管是client層的website，還是服務層的service，加上其它技術，比如叢集或負載均衡之類，可以很友善進行擴充。服務的實作邏輯也可以友善的單獨的修改替換(前提是服務契約相對穩定)
但如果應用的規模較小，出于成本考慮，完全有可能Service層和Website Client部署在一台機器上，雖然1個IIS上架2個站點完全沒有問題，但是總歸有點不爽，既然都在一台機器上了，為啥還要自己調用自己，增加無謂的開銷呢？
最好是在不修改原來代碼的前提下，通過簡單的配置檔案修改，就能讓原來遠端調用WCF的方式，改成直接調用本地DLL程式集，反過來也一樣，這樣就比較靈活了。事實上，我們公司很多項目就是這樣處理的，規模小的應用，直接全都部署在一台機器上，等應用規模上去了，再分開部署，代碼完全不用動，隻要修改相關配置即可。
原理其實非常簡單，反射即可，先在Client層的web.config或app.config中，增加類似以下節點：
View Code
這樣調用時，隻需要一行代碼即可：