Ido Flatow最近發布了一篇文章,其中講述了一系列WCF將在.NET 4.5中做出的變更。
由於減少了噪音,WCF自動產生的設定檔會大大減小。從WCF的第一個版本開始,開發人員就發現他們需要維護有接近30種設定的app.config檔案,而事實上都只是預設值。瞭解設定檔的人會刪除冗餘的設定,但是遺憾的是很多人都沒有學到這項技巧。有了WCF 4.5,設定檔預設只會有綁定類型和名稱。
當然,這會引出相關的培訓問題,“我怎麼知道設定都是什麼呢?” 為了回答這個問題,我們還會在設定檔中看到訊息提示和自動完成的功能。這不僅僅是基於schema的提示;如果你在配置終端,要行為或者配置的名稱,它就會非常智能地幫你列舉出來。如果配置項、契約類型或者行為名稱的拼字有誤,這甚至會包括對編譯器警告的支援。
對於那些直接使用WSDL的人,也有好訊息。WCF 4.5現在會在單獨的請求中返回完整的WSDL。而之前,它只會包括部分WSDL,還需要擷取一系列匹配的XSD檔案。想要使用這種方法,你需要使用?singleWsdl查詢字串而不是?singleWsdl。
儘管把WCF部署在Windows服務中是完全可以接受的,但是大多數開發人員會在工作中繼續使用IIS。為什麼不呢,IIS提供了對很多特性的內建支援,像身分識別驗證、狀態管理以及過程回收等。但是在這個模型中還有一些微軟正在努力解決的限制。例如,當前開發人員需要在兩個地方配置哪種身分識別驗證方式能夠得到支援。如果他們意外忘記了sync,那麼服務就會停止運行。WCF 4.5讓開發人員可以把驗證方式類型設定為“InheritedFromHost”,讓服務遵從IIS的方式,從而避免了這類特定的缺陷。
遺憾的是,這隻是部分的修正。如果IIS正好啟用了多種身分識別驗證類型,那麼用戶端只會承認第一個。用戶端開發人員可以對其重寫以使用另一種類型,但前提是他們可以找到另一種方式。請注意這完全是用戶端工具的問題,WSDL會列出所有選項。
在WSDL中存在的缺陷在於為HTTPS服務連接埠建立URI的方面。從.NET 4.0開始,WCF就有了為每種綁定類型(HTTP、TCP等)自動產生連接埠的選項。遺憾的是,HTTPS並沒有在那次包含進來,這個疏忽會在.NET 4.5中改正。Ido Flatow提到,HTTPS的版本會發送機器名而不是用來請求WSDL的主機名稱。當使用web場的時候這會導致問題。
另一種缺陷在於WCF使用流資料的方式。Ori認為,
當你把WCF服務部署在IIS中時,即便你不使用ASP.NET相容模式,也會佔用一些ASP.NET的管道,這在MSDN的文章《WCF 服務和ASP.NET》中有記錄(你需要尋找關於PostAuthenticateRequest事件的部分)。在.NET 4中存在ASP.NET方面的設計缺陷,它會導致傳送給WCF的請求緩衝在ASP.NET中。這種緩衝行為會導致多種主要的副作用:
這不僅會讓處理請求產生延遲,特別龐大的內容甚至會溢出到硬碟上。這也會在WCF 4.5中得到修正。
查看英文原文:Lighter Configuration Files and Better ASP.NET Support with WCF 4.5
中文原文InfoQ:WCF 4.5:設定檔更小,對ASP.NET的支援更好