我正在使用Jquery开发网站的早期阶段。我在思考是使用Pagemethods还是WCF服务类。我在stackoverflow上看到一个答案,建议尽可能在所有未来需求中都使用WCF。非常感谢如果有人能解释一下决定因素和安全问题。
我正在使用Jquery开发网站的早期阶段。我在思考是使用Pagemethods还是WCF服务类。我在stackoverflow上看到一个答案,建议尽可能在所有未来需求中都使用WCF。非常感谢如果有人能解释一下决定因素和安全问题。
如果Page Method或ASMX ScriptService符合您的要求,那么使用它们是没有问题的。
WCF确实为表格带来了额外的功能、灵活性和特性,但这也意味着额外的复杂性。如果您不打算使用这些改进,那么它只会带来复杂性。
有人会告诉你ScriptService方法是“遗留”的,基于MSDN文章上的一些标题文本,但这被夸大了。事实上,同样的文章的新版本不再带有免责声明。放弃它必须是一个有意识的决定。在可预见的未来,服务器端ASP.NET AJAX和ScriptServices仍将存在。
如果您只是在与调用它的页面相同的项目中托管AJAX回调端点,那么您真的无法击败Page Methods和ScriptServices的易用性。我从来没有看到过一个好的论据,证明WCF的复杂性惩罚在这种情况下是合理的,除了关于过时的FUD论点。
ScriptService/Page方法的JavaScriptSerializer比WCF的DataContractJsonSerializer更灵活地反序列化DateTime和枚举输入参数,这通常非常方便。
我最近面临了类似的决定 - 这是一些强烈影响我们决策的因素:
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-在这种情况下,此问题没有意义。PageMethods使用了许多与ASMX Web服务相同的技术。这种技术已经停滞不前,预计不会得到增强,只有关键错误才会被修复。这并不是一个生产就绪的代码基础。