在C#中存在方法重載，我們可以定義相同方法名但是參數類型或者個數不同，進而實作方法的重載功能。在wcf中，如果能夠實作方法重載，那麼我們就可以傳遞不同類型的資料，讓服務傳回不同的結果。這真是一個不錯的主意，但是wcf能夠實作方法重載嗎？
我們先簡短的思考一下：wcf服務和用戶端通過soap消息（也就是xml資料）進行互動，soap消息會包含參數類型以及傳回值類型，還有方法名，用戶端或服務會解析soap消息，轉換成本地對象，從技術功能上說可以實作方法的重載，但是考慮到soap消息的傳輸安全性問題，soap消息可能會被更改，是以從這方面來說方法的重載就不太可能實作了，因為服務的調用要的就是穩定、可靠。
當然這些都是我們自己的推測，wcf服務究竟能不能實作方法的重載還是我們要自己測試以後才可以知道。
我們建立了一個具有相同方法名，但是參數類型不同的方法重載，具體的服務托管與寄宿我們有很多資料講述，這裡不再多說，下面我們運作托管程式來看看究竟會發生什麼？
出現了一個異常資訊，提示我們同一協定中不允許出現兩個相同的操作。然後提示我們可以通過OperationContractAttribute的Name屬性更改方法在用戶端顯示的名稱。好，我們按照它說的做，通過Name更改操作的名稱。
我們更改了OperationContractAttribute的Name屬性的值，讓她們可以在用戶端顯示不同的名稱。
我們可以看到在用戶端，調用服務的操作名稱已經更改了。
再次運作托管程式，就可以正常的啟動服務。這就告訴我們在wcf中不存在方法重載這一說，當然這有個前提是在wcf服務中。
回歸主題，今天的主題是wcf的操作重載，也就是說我們要實作wcf的方法重載，既然wcf本身不提供，我們自己就要想辦法來通過改動來實作它。
wcf的操作重載分為服務重載和用戶端重載兩種方式。
剛才說到的就是服務端的重載，通過OperationContract的Name屬性重命名方法在用戶端顯示的名稱。現在我們來看用戶端重載，首先我們不通過添加服務引用的方式，我們通過svcutil.exe實用工具生成用戶端的代理類。
中間的位址是服務中繼資料的位址，/out:proxy.cs 表示最後輸出的檔案，/noconfig 表示不聲稱配置檔案，我們一般不會讓svcutil來幫助我們生成配置檔案，因為它會像添加了服務引用一樣，把我們的配置檔案搞的很亂，并且會為我們添加很多的預設值，這可能不是我們想要的結果。
生成的代理類檔案為：
請注意代理類中的我加紅色的那部分方法名，很熟悉吧，不錯，那就是我們通過Name屬性更改後的方法名，在用戶端生成的代理類中，也是和服務端方法保持了一緻。那麼我們如何讓用戶端代理實作方法重載呢？其實我們有了本地的代理類，要實作方法重載可以說是非常之簡單，我們可以更改方法名，讓它們相同就可以實作。
其實用戶端的重載我們也隻是修改了方法的名稱，但是我們仍然添加了Name屬性的值用來區分不同方法的調用，這也是服務端的重載功能的展現。
用戶端重載調用成功。
課後總結：
服務端重載的實際意義不大，因為不能在用戶端調用的時候真正實作重載。
用戶端的重載還有點實際作用，最起碼友善用戶端的方法調用功能，但是要實作用戶端的重載相比直接添加服務引用，我們的工作量還是顯著的增加，并且用戶端重載還是記得要添加用戶端接口OperationContractAttribute的Name屬性的值。
用戶端重載還有另外一個好處，其實這個應該算不上重載的好處，就是我們直接生成的代理類，可以對代理做更多的控制操作，例如添加預設值等。
wcf的操作重載屬于服務契約的範疇，雖然說意義不大，但是我們可以對比.Net中的方法重載來體會其中的不同點以及原因。其實原因應該是wsdl不支援操作重載的緣故。
我又回來了，回到了技術最前線，