我发现每个操作打开一个连接并不会显着降低性能。我已经运行了一年多的本地Chrome扩展,涉及大量的indexedDB操作,并且已经分析了其性能数百次,并且从未目睹将连接视为瓶颈。这些瓶颈会导致不正确使用索引或存储大块数据块。
基本上,不要将您的决定放在表现上。这在连接方面确实不是问题。
这个问题实际上就是您的代码的人体工程学,您与API的对抗程度如何,您的代码在您看到它时感受到的直观程度,您认为代码的可读性,对新鲜眼睛的欢迎程度(你自己一个月后,或其他人)。处理阻塞问题时,这非常显着,这是间接处理应用程序模式的问题。
我的个人意见是,如果你对编写异步Javascript感到满意,可以使用任何你喜欢的方法。如果您与异步代码纠缠在一起,选择始终打开连接将避免任何问题。我永远不会推荐使用一个全局页面生命周期变量给更新的异步代码。您也在页面的整个生命周期内将变量留在那里。另一方面,如果你发现异常微不足道,并且找到更适合的全局数据库变量,那么一定要使用它。
编辑 - 根据您的意见,我想我会分享我的个人偏好的一些伪代码:
function connect(name, version) {
return new Promise((resolve, reject) => {
const request = indexedDB.open(name, version);
request.onupgradeneeded = onupgradeneeded;
request.onsuccess =() => resolve(request.result);
request.onerror =() => reject(request.error);
request.onblocked =() => console.warn('pending till unblocked');
});
}
async foo(bar) {
let conn;
try {
conn = await connect(DBNAME, DBVERSION);
await storeBar(conn, bar);
} finally {
if(conn)
conn.close();
}
}
function storeBar(conn, bar) {
return new Promise((resolve, reject) => {
const tx = conn.transaction('store');
const store = tx.objectStore('store');
const request = store.put(bar);
request.onsuccess =() => resolve(request.result);
request.onerror =() => reject(request.error);
});
}
随着异步/ AWAIT,有没有在你的工作多余conn = await connect()
线摩擦力太大功能。
干杯,这正是我需要知道的事情。我想支持多个选项卡,但我也将使用服务工作者,所以我不应该得到一个选项卡获得不同版本(我认为)的场景。更值得关注的是一个选项卡上的连接阻塞另一个选项,我特别想避免这种连接。 – Keith