本期特邀資深.NET技術專家、暢銷書作者蔣金楠老師，針對WCF的擴展之“道”的問題給予解答，歡迎網友積極提問，與專家一起討論!
專家博客：http://jinnan.blog.51cto.com
查看本期門診精彩實錄：http://doctor.51cto.com/develop-267.html
參與最新技術門診：HTML5的Mobile Web App開發之路
精選本期網友提問與專家解答，以供網友學習參考。
Q: 蔣老師好：
我對WCF還是道聽途說，以前接觸過SharePoint裏面的工作流，現在Web編程中OA的應用也很普遍。以前搞個網絡通訊程序總是感覺很繁瑣。請問老師，作爲微軟重新包裝的通信技術，WCF有哪些方便開發的特點呢？
A:
你說的沒錯，要自行實現網絡通信（比如採用Socket）是一件非常繁瑣，而且不容易做好的事情。所以微軟爲了解決這個問題，開發了一系列的分佈式/中間件技術，比如COM/DCOM、Enterprise Service、.NET Remoting、XML Web服務、MSMQ等。
通過合理利用上面這些分佈式技術完全可以創建一個完美的、能夠適用不同層次需求的分佈式應用。但是這些單一的技術和產品專注於某一特定的領域，並且具有完全不同的應用編程接口（API），這使得開發人員很難從容地從其中一種轉移到另一種。基於這樣的原因，急需一種全新的通信框架來整合以上這些技術，這就是WCF。
WCF的目的在於讓開發人員不需要關注底層地通信設置是消息交換層面的細節，只需要關心如何通過接口定義服務契約、實現接口編寫服務操作的功能、通過代碼生成機制創建服務代理，通過方法調用實現遠程的服務消費。一切都如此簡單、容易，對於網絡編程一竅不通的開發者都可以進行WCF服務編程。
Q:
蔣老師：
你好！
WCF 由於集合了幾乎由 .NET Framework 所提供的通信方法，因此學習曲線比較陡峭，開發人員必須要針對各個部份的內涵做深入的瞭解，才能夠操控 WCF 來開發應用程序。請問WCF如何使用SOAP與ASMX進行交互？
對於初次涉及WCF的朋友應當首先學習那些基礎知識呢？
A:
如果要對WCF具有一個全面而徹底地瞭解，確實需要掌握太多的知識，比如.NET Framework、基本的網絡知識、SOA設計思想、WS-*、消息隊列、分佈式事務以及MSDTC等等。
但是“學習曲線”卻並不陡峭。對於一個沒有接觸過WCF的開發人員，他寫第一個WCF的Hello World肯定比寫一個Socket Hello World要容易得多。WCF雖然是一個基於消息的通信框架，但是它封裝了所有的通信細節，對於最終的WCF編程人員甚至接觸不到消息。我們接觸到的更多的是反而是如何通過接口定義服務契約，如何實現接口定義相關的業務邏輯。WCF不是單純地解決數據通信的問題，它是一個面向應用層面的分佈式技術，它的目的就是讓開發人員只需要關注業務邏輯的定義，所以它和Socket並沒有可比性。
也就是說技術我們不瞭解網絡通信是怎麼回事，不知道消息是如何生成的，我們依然可以利用我們掌握的C#或者VB.NET進行WCF服務編程。所以WCF的入門反而是很容易地。
學習WCF是一個循序漸進的過程，初學者應該先了解WCF的基本編程方式，明白終結點的ABC三要素是什麼，主要解決什麼問題，服務端和客戶端的配置大體具有怎樣的結構等。如果想對WCF具有更加深刻的理解，我們的眼光就不應該只是關注這些編程方面的知識點了，而是應該看到在整個WCF客戶端和服務端消息的生成和處理流程。
至於你提到的WCF與ASMX交互問題，我們應該這樣來考慮：WCF是一個消息處理框架，WCF與其它平臺的Web Service（泛指）進行集成主要體現在：
1、WCF客戶端能夠調用其它平臺Web Service；
2、其他平臺客戶端能夠調用WCF Service
客戶端和服務能夠正常交互的唯一前提是交換的消息能夠被彼此識別。由於WCF採用標準的SOAP，並且對WS-*提供支持，意味着它進行處理的消息的格式和消息處理方式都是“標準”的，其他平臺的Web Service如果也支持同一套標準，它們交互就不是問題。
Q: 蔣老師你好，我想問你一個問題。因爲在實際項目中還沒有具體的使用過這個技術，目前WCF給我的感覺就是，WCF是微軟對於各種通信技術的一個封裝，能夠很容易的通過一些配置來達到不同的通信效果。那麼WCF這個技術我感覺只是在多系統集成、數據交互的時候纔會用到，一般的應用不會用到這個，跟以前的web service很類似。你認爲我的這些觀點正確嗎？
A:
你的理解是對的，WCF就是廣義的Web Service，系統之間的集成確實一個WCF主要解決的一個問題。不過這裏的集成體現在以下兩個方面：
與既有系統的集成：現有的系統包含一些可重永的功能，爲了節約成本，可以通過WCF對它進行封裝並被新的系統使用。
對未來系統的集成：對於一個企業來說，一個完整的解決方案往往需要多個系統協作完成，我們在開發新的系統的使用，應該考慮目前的功能的潛在的重用性。對於這些具有重用性潛力的功能，在設計的時候就應該採用SOA的原則進行設計。
除了集成，有些應用採用WCF就是當成一種單純的分佈式技術在使用，他們更多地還是考慮“部屬”方面的問題：如果將業務邏輯進行集中部屬（比較典型的部屬方式是，Web Server部屬的邏輯僅僅涉及簡單的UI處理，而所有的業務邏輯則定義成WCF服務部屬在Application Server中），可以單獨地實施安全策略和負載均衡等。
Q:
蔣老師您好 ： 我現在有個WCF RESTFUL 服務中IEmployees 契約中 我想加入一個方法使 傳入一個List<Employees>的集合 用來執行批量新增人員應該如何處理？
例如： void CreateMore(List<Employees> employees);
應該如何定義？ 如何調用？ 如果是其他平臺調用例如iphone，有沒有可以通用的調用方法？
A:
WCF REST和針對SOAP的WCF定義服務契約的時候除了需要使用WebGet或者WebInvoke指定一個Uri模板和HTTP Method之外，並沒有什麼不同。至於實現服務契約接口的服務類型來說，就更加沒有區別了。
如果採用自我寄宿的方式，應該採用WebServiceHost，而不是ServiceHost（其實使用它也可以，只是需要作其他相關的設置）。使用的綁定類型爲WebHttpBinding。如果使用IIS寄宿，不要忘了添加WebBehavior行爲。
既然叫作WCF REST，意味着它是完全基於Web的，其服務調用方式就是一次單純的HTTP請求/響應的過程，和我們普通訪問某個Web頁面沒有本質的區別。所以說不論採用什麼客戶端技術，處於什麼平臺，你只需要向服務終結點地址發送HTTP方法和數據格式相匹配的HTTP請求，服務端就能夠正確處理請求和執行相應的服務操作，並最終將處理結果作爲響應返回給客戶端。
WCF REST能夠職能地根據請求的媒體類型決定採用的消息格式化方式。以你提出的這個例子來說，如果請求的媒體類型被設置爲“application/xml”，你可以採用XML的方式來封裝添加的Employee列表。如果採用“application/json”，Employee列表可以通過Json格式來表示。響應消息格式化也可以根據請求職能地完成。
關於WCF REST，在我的Blog上也有一系列文章：
[01] 一個簡單的REST服務實例
[02] WebHttpBinding與消息編碼
[03] Web消息主體風格（Message Body Style）
[04] 幫助頁面與自動消息格式(JSON/XML)選擇
[05] WebServiceHost有何特別之處？
[06] UriTemplate、UriTemplateTable與WebHttpDispatchOperationSelector
[07] 通過ASP.NET Output Caching實現聲明式緩存
[08] 提高性能的一個有效的手段：條件資源獲取（Conditional Retrieval）
[09] 解決資源併發修改的一個有效的手段：條件更新（Conditional Update）
最後再說一點，由於WCF在設計之初主要是爲了SOAP而設計的，而WCF REST是通過WCF的擴展實現的。我個人喜歡將SOAP和REST稱爲“重量級”和“輕量級”消息通信，在重量級通信框架WCF下實現輕量級的REST，我覺得有點“牛刀殺雞”的感覺。所以我們不太贊成大家使用WCF REST，ASP Web API反而是更好的選擇。
Q:
蔣老師您好，您的答案中“ 如果請求的媒體類型被設置爲“application/xml”，你可以採用XML的方式來封裝添加的Employee列表。”
您的意思是我將 void CreateMore(List<Employees> employees);替換爲 void CreateMore(string employeesXML);
然後根據調用傳遞的XML 解析成List<Employees>在操作嗎？
如果是基於WCF SOAP去提供一個服務給IPAD調用需要注意什麼嗎？
A:
我們無須爲消息的格式改變操作的定義（參數的類型）。也就是說，不論是XML格式，還是JSON格式，CreateMore的參數都可以定義成IEnumerable<Employees>。WCF REST會根據請求消息的媒體類型動態地選擇不同的消息格式化器進行序列化和反序列化。
另一個關於iPad應用如何調用基於SOAP的WCF Service，我個人沒有從事IOS和Object-C相關的經驗，所以回答不了這個問題。不過從原則上講，不論什麼客戶端，對於WCF Serivice的調用最終都體現爲根據發佈出來的元數據（主要體現爲WSDL）生成相應的SOAP消息。
Q:
最近使用wcf是在SL3.0版本下，wcf可以理解爲和webService類似的東東，在別的軟件平臺上我看到也有用服務這個概念的，例如WebGIS中使用soap、wsdl（才疏學淺，表達不準確，測試接口的時候用的是這個服務地址），而處理的返回結果可能是幾十萬個數據（如電話號碼，座標點之類的）的字符串表達，前端使用GIS提供的這樣服務，獲取數據然後表達出來，速度確實很快！
弱弱的問問：1、如果使用wcf進行上述類似的數據處理，返回大數據量的結果，如果保存爲對象列表（List結構之類的）幾十萬個對象保存在List中，前端進行接收，會不會造成性能的降低呢？
2、wcf能不能像您說的，提供可擴展的功能來實現呢？或者說便於高性能的傳輸和轉換？小人總是覺得使用wcf傳輸幾十萬個對象，好像有點過分，這個沒有試驗過，只是覺得可能存在這麼個問題。 謝謝您，浪費您的時間看我的如此幾個笨笨的問題了。
A:
1. 由於WCF涉及到網絡轉輸、序列化、編碼，甚至簽名和加密等，大數據量的處理肯定有性能問題，這是所有技術都會遇到的問題，因爲所有這些環節是避免不了的。實際上對於OLTP，來說這種大數據量的處理是很少的，即使出現了我們覺得也應該採用“分批”獲取的策略。對於OLAP來說，它們對性能的要求不是那麼高，甚至不具有實時性的要求。
2、WCF的可擴展性意味着我們可以通過自定義相應的組件來定製某個環節的消息處理，比如我們定義更加高效的序列化器、消息編碼器、傳輸信道，甚至可以對消息進行壓縮傳輸，根據性能和安全的要求採用適合的安全策略（安全和性能是互相制約的，我們往往需要根據具體需求對兩者進行權衡）。總之，整個消息處理的管道都是可以定製的，如果我們具有比微軟更好的實現方式，完全可以替換掉現有的組件，就像是我們組裝電腦一樣，可用選用任意廠商的CPU、內存、主版、硬盤等