Jquery WCF和Pagemethods

Question

我正處於使用Jquery開發網站的早期階段。我想知道是否使用Pagemethods或WCF服務類。我在其中一個答案中看到，儘可能多地使用WCF將來的所有需求。如果有人能夠解釋什麼是決定因素和安全隱患，高度讚賞。

Answer 1

PageMethods使用了ASMX Web服務所使用的大部分相同技術。這種技術是停滯不前的。預計不會得到增強，只有重要的錯誤纔有望得到修復。這對於生產就緒的代碼來說不是一個好的基礎。

Answer 2

如果使用Page Method或ASMX ScriptService滿足您的要求，則沒有任何問題。

WCF確實給表格帶來了額外的功能，靈活性和功能，但這帶來了額外的複雜性。如果你不打算使用這些改進，那麼只有帶來了複雜性。

人們會告訴你，ScriptService方法是「遺留」的，它基於一篇MSDN文章中的一些標題文本，但是這種方法被誇大了。實際上，newer versions of those same articles不再承擔免責聲明。放棄它必須是一個有意識的決定。在可預見的未來，服務器端ASP.NET AJAX和ScriptServices不會在任何地方。

如果您只是在與將調用它的頁面相同的項目中託管一個AJAX回調終結點，那麼您確實無法擊敗Page Methods和ScriptServices以便於使用。我從來沒有看到過一個很好的論點，說明爲什麼WCF的複雜性懲罰在這種情況下是合理的，除了關於過時的FUD爭論之外。

ScriptService/Page方法的JavaScriptSerializer也比WCF的DataContractJsonSerializer稍微更靈活地反序列化DateTime和枚舉輸入參數，這通常非常方便。

Answer 3

我最近遇到了類似的決定 - 這裏的一些事情，強烈地影響我們的決定：

ASMX和ASP.NET服務中運行PageMethods，這樣他們就可以共享相同的會話數據的ASP.NET頁面。如果您大量使用會話（我不會說這是否是一種好的做法 - 完全是一個不同的討論），然後能夠在您的頁面調用和web服務調用之間共享它可能是一個重大的好處。在我們的例子中，我們確實在會話中存儲了某些授權信息 - 如果我們選擇將我們的Web服務實現爲WCF，我們還需要在Web服務和ASP.NET服務之間推出我們自己的單點登錄框架。沒有錯，但它是設計/開發/測試時間，你可能不想投資。

如果您的Webservice託管在與您的ASP.NET服務不同的地址/端口上，那麼從您的頁面調用它的所有調用都將被視爲跨站點腳本（XSS），並且會受到瀏覽器的顯着限制。有一些解決方法（主要以JSONP的形式），但這些解決方法也有侷限性;例如，只支持GET類型的http請求。由於ASMX/PageMethods在ASP.NET服務器本身內執行，因此不會被視爲XSS請求。當然，如果您可以保證您的WCF服務將始終與您的ASP.NET服務器部署在相同的地址/端口上，那麼它們也不會被視爲XSS - 在這種情況下，此問題是無根據的。從面向未來的角度來看，WCF可能比ASMX/PageMethods更注重MS（補丁，增強等）。但是，NO技術是完全面向未來的（您認爲我們從現在開始將不會再編寫WCF服務，是嗎？）。因此，您必須針對ASMX未來可能的棄用情況來衡量自己的薪水水平（或您的客戶）。