深入显出dojo/request

深入浅出dojo/request
难度：中等Dojo版本：1.7原作者：Bryan Forbes译者：Oliver (zhuxw1984@gmail.com)原文链接：http://www.sitepen.com/blog/2012/08/21/introducing-dojorequest/
随着Dojo向着2.0大步迈进，我们已开始致力于为开发人员提供能在任何JavaScript环境下保持高效生产力的工具。这意味着我们所创建的API必须在所有环境下都保持一致。从这个角度看，有一个领域的API总是被遗漏，那就是Dojo的IO函数。我们已经为开发人员提供了在浏览器中发起请求的方法（dojo.xhr*, dojo.io.iframe, dojo.io.script），但有些人不太喜欢这些API所表现出的不一致性（例如dojo.xhrGet以及dojo.io.script.get，等等）。另外，我们还从来没有提供一套服务器端的实现；就算提供了，也肯定是另一套不同模块和API，大家就又需要记忆更多东西了。
在Dojo1.8发布之际，我们隆重推出dojo/requestAPI。这套API在所有的浏览器、所有请求方法、甚至所有JavaScript环境上都是一致的：

request.register(/^\/service1\//, function(url, options){    var promise = xhr(url, lang.delegate(options, { handleAs: "json" })),         dataPromise = promise.then(function(data){            return data.items;        });    return lang.delegate(dataPromise, {        response: promise.response    });});request.register(/^\/service2\//, function(url, options){    var promise = xhr(url, lang.delegate(options, { handleAs: "json" })),         dataPromise = promise.then(function(data){            return data.data;        });    return lang.delegate(dataPromise, {        response: promise.response    });});

现在所有在用户界面中用到的服务请求都可以通过request(url, options).then(...)的形式来使用，并且它们都会接收到正确的数据。随着开发过程的进行，某个服务端团队可能决定改让/service1在data属性中以JSON格式返回数据项，而/service2则以XML的格式返回。如果不使用注册机制，这将导致大量的代码改动。有了注册机制，我们已经将我们的widget和store所需要的接口和服务所能提供的接口解耦了，这意味着服务器端团队的决定只会导致两处代码改变：在我们的两个provider中。理论上，我们甚至能将用户界面与URL进行进一步解耦，通过使用通用的URL让我们的注册机制自动将正确的服务终端映射到正确的provider上。这就避免了服务终端的改动导致的前端代码的大量修改。
这种解耦也可以拓展到测试上。通常在单元测试中无法获得远程服务：远程数据可能变化，远程服务器也可能不可用。这也是为什么推荐使用静态数据做测试。但如果我们的widget和用户界面把服务终端和对应请求都写死在里面了，我们还怎么去测试呢？而如果我们使用了dojo/request/registry，只需要注册一个专门为测试任务返回静态数据的provider就行了，所有的API调用都不需要修改，现有应用中不需要重写任何代码。
结论可见，dojo/request是为开发者编写的：对于简单的场景有简单的API，对于复杂场景也有非常灵活的选项。
相关资料更多关于dojo/request的学习资料请参考：

深入显出dojo/request

热点推荐