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未来可能的弃用情况来衡量自己的薪水水平（或您的客户）。