Jquery WCF与Pagemethods的比较

Question

我正在使用Jquery开发网站的早期阶段。我在思考是使用Pagemethods还是WCF服务类。我在stackoverflow上看到一个答案，建议尽可能在所有未来需求中都使用WCF。非常感谢如果有人能解释一下决定因素和安全问题。

- rasi

Answer 1

如果Page Method或ASMX ScriptService符合您的要求，那么使用它们是没有问题的。

WCF确实为表格带来了额外的功能、灵活性和特性，但这也意味着额外的复杂性。如果您不打算使用这些改进，那么它只会带来复杂性。

有人会告诉你ScriptService方法是“遗留”的，基于MSDN文章上的一些标题文本，但这被夸大了。事实上，同样的文章的新版本不再带有免责声明。放弃它必须是一个有意识的决定。在可预见的未来，服务器端ASP.NET AJAX和ScriptServices仍将存在。

如果您只是在与调用它的页面相同的项目中托管AJAX回调端点，那么您真的无法击败Page Methods和ScriptServices的易用性。我从来没有看到过一个好的论据，证明WCF的复杂性惩罚在这种情况下是合理的，除了关于过时的FUD论点。

ScriptService/Page方法的JavaScriptSerializer比WCF的DataContractJsonSerializer更灵活地反序列化DateTime和枚举输入参数，这通常非常方便。

- Dave Ward

Answer 2

我最近面临了类似的决定 - 这是一些强烈影响我们决策的因素：

ASMX和PageMethods在ASP.NET服务内运行，因此它们可以与ASP.NET页面共享相同的会话数据。如果您大量使用会话（我不会讨论这是否是一个好的实践 - 那是完全不同的讨论），那么能够在页面调用和Web服务调用之间共享它可能是一个重要的优势。在我们的情况下，我们实际上将某些授权信息存储在会话中 - 如果我们选择将我们的Web服务实现为WCF，则还需要在Web服务和ASP.NET服务之间自己编写单点登录框架。这没有任何问题，但这可能是您不想投资的设计/开发/测试时间。

如果您的Web服务托管在与ASP.NET服务不同的地址/端口上，则来自您的页面的所有调用都将被视为跨站脚本（XSS），并且将受到浏览器的显着限制。有一些解决方法可以解决这个问题（主要是JSONP形式），但这些解决方法也有其限制，例如，仅支持GET类型的HTTP请求。由于ASMX/PageMethods是在ASP.NET服务器内部执行的，因此它们不会被视为XSS请求。当然，如果您保证您的WCF服务始终部署在与ASP.NET服务器相同的地址/端口上，它们也不会被视为XSS-在这种情况下，此问题没有意义。

从未来的角度来看，很可能WCF会比ASMX/PageMethods得到更多来自MS的关注（补丁、增强等）。但是，没有任何技术是完全面向未来的（您不认为10年后我们仍然会编写WCF服务吧？ ;)）。因此，您真的必须根据自己（或客户）对于ASMX可能被废弃的未来的舒适水平进行衡量。

- mikemanne

---

在深入进行项目之前容易忽略的一件事情是，当涉及到解析日期和枚举输入参数时，ASMX ScriptServices的JavaScriptSerializer比WCF的DataContractJsonSerializer更灵活。 - Dave Ward

Answer 3

PageMethods使用了许多与ASMX Web服务相同的技术。这种技术已经停滞不前，预计不会得到增强，只有关键错误才会被修复。这并不是一个生产就绪的代码基础。

- John Saunders