在JavaScript應用程序中實現數據源協調

2020-03-24 16:57:08

字體：大中小

來源：轉載

供稿：網友

異步數據源中存在的問題就是：它們不是同步的。尤其是，通過 HTTP 協議請求傳遞的數據可能會遠遠晚于預期到達，或者請求發生超時，或者完全失敗。任何 tcp 層協議都具有不可靠性，但是 html' target='_blank'>Ajax 應用程序可能與多個服務器有數據依賴關系，而這些服務器將影響到整個 Web 應用程序。處理數據依賴關系并非 Ajax 應用程序的特別之處。各種各樣的應用程序都使用信號量、隊列、共享變量等在進程中與狀態進行通信；在本例中，進程通常指的是數據獲取請求。但是，Web 應用程序中的超時和其他服務器或網絡問題多于大多數其他類別的應用程序（尤其是與嚴格執行本地運行的應用程序相比）。此外，在數據源（甚至同一數據源中的多個請求）中的時序變化方面，基于 Web 的應用程序也要高于大多數其他類型的應用程序，甚至要高于使用基于網絡的資源（如數據庫）的多數應用程序。請求狀態和超時我們將遇到的大多數代碼示例都是關于異步 Ajax 使用 XMLHttpRequest() 檢查是否接收到 200 OK 狀態碼。我建議在檢查的內容中添加一些其他可行的狀態，以及一個用于表示完全超時的 “偽狀態”。我在近期的一篇 developerWorks 技巧 “使用會話狀態避免不必要的 Ajax 流量”（參見參考資料獲得文章鏈接）中，我提供了一個利用 304 狀態碼的示例，該示例仍然是個不錯的想法。適當處理各種 HTTP 狀態碼是個不錯的想法。針對 2xx 狀態碼（而不是 200 OK）的操作仍然有點懸而未決：比如說，如果應用程序將創建一個服務器資源，那么您可能希望檢查 201 Created 狀態碼并查看響應中的 URI。標準情況下，客戶機必須透明的重定向狀態碼 301、302、303 和 307。因此，我們實際上不必擔心它們，因為它們最終將得到 200 狀態（或者是超時、4xx 和 5xx 狀態）。區別處理 4xx 錯誤和 5xx 錯誤可能是一個很好的方法。概括地說，4xx 狀態碼（尤其是常見的 404 Not Found 錯誤）可能表示客戶機所使用 URL 中存在一些問題。5xx 錯誤表示服務器存在問題，通常只需等待一段時間并重試便可解決該問題。與處理各種服務器錯誤同樣重要的情況是，有時服務器會無限期掛起，而根本不會返回任何響應。掛起實質上等同于 5xx 狀態碼，不同之處就是我們無法檢查 XMLHttpRequest().status 狀態碼來識別它們。為此，我們可以使用一個 setTimeout() 計時器來取消超時請求。將相關檢查結合在一起，我們的 Ajax 數據源請求可能類似于清單 1：清單 1. 數據源請求的健壯處理 function getResource(uri, data_callback, error_callback, timeout) {
var tryAgain = function () {
getResource(uri, data_callback, error_callback, timeout);
}
var r = new XMLHttpRequest();
var timer = setTimeout(
function() {
r.abort();
r.onreadystatechange = null;
setTimeout(tryAgain, timeout);
},
timeout);
r.open("GET", uri, true);
r.onreadystatechange = function() {
if (r.readyState != 4) {
// Ignore non-loaded readyStates
// ...will timeout if do not get to "Loaded"
return;
}
clearTimeout(timer); // readyState==4, no more timer
if (r.status==200) { // "OK status"
data_callback(r.responseText);
}
else if (r.status==304) {
// "Not Modified": No change to display
}
else if (r.status = 400 r.status 500) {
// Client error, probably bad URI
error_callback(r)
}
else if (r.status = 500 r.status 600) {
// server error, try again after delay
setTimeout(tryAgain, timeout);
}
else {
error_callback(r);
}
}
r.send(null);
return r;
} 當然，我們可以在 getResource() 中加入各種增強。比如說，在超時或服務器錯誤狀態事件中，我們可以在延時之后調用 tryAgain()。或者，我們可能希望在這兩種情況下使用一些其他的回調。傳遞的 error_callback() 函數將用于下面這種情況，即不希望再次發送重復請求，但是常常會發生這種情況。數據協調給出的 getResource() 函數可能會無限制地等待，獲取數據源并將其提供給 data_callback()。但是，該數據回調自己可能需要依賴其他數據的可用性。同時操作多個數據源的最簡單方法就是將它們的內容存儲在一個全局變量中，并當該數據被使用時清空這些變量。比如說，基本的回調方法可能類似于清單 2：清單 2. 兩個源的基本數據回調 var other_data = null;
function processOtherData(responseText) {
other_data = responseText;
}
function processData(this_data) {
var delay = 1000; // Keep trying at 1-second intervals
if (other_data == null) {
setTimeout(function() { processData(this_data); }, delay);
return;
}
// We have both this_data and other_data
displayThisAndThat(this_data, other_data);
// Reset other_data now that we have consumed it
other_data = null;
} 應用程序將調用 getResource(uri1,processOtherData,...) 方法，然后將在別處調用 getResource(uri2,processData,...) 方法。后面這個調用將運行一個回調從內部 “輪詢” other_data 直到它實際填入了數據，并在該數據被處理后將它清空。另一個信號量可能與以下操作相關，避免重復后面這個調用，直到第一次嘗試成功并且/或針對延時的 processData() 調用 clearTimeout()，有利于更新的請求。結束語數據協調的具體應用在任何種類的應用程序中的復雜度都會有所不同 — 而不僅僅是 Ajax 應用程序。本文所提供的示例只使用一個主數據表示函數 processData() 和一個有用的回調來獲取額外的數據，即 processOtherData()。但是，這種模式非常容易應用到廣泛的相互依存的數據源。在任何情況下，getResource() 函數都是一個很好的通用框架，它可用于解決在 HTTP 上獲取數據時遇到的問題。通常，該訪問最終都會成功，前提是在表達請求時沒有發生客戶端錯誤。也就是說，短暫的網絡和服務器錯誤只意味著延時，而不是故障。當然，在 Ajax 應用程序中，我們需要使用一些特別的技巧來從多個域中獲取數據。其方法通常是將 XMLHttpRequest() 對象放置在單獨隱藏的 IFrames 中以輪詢不同的域，不過這對異步協調毫無特別之處
html教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。

上一篇：對js的一些感悟與分享

下一篇：深入分析JS函數