什么是更快的基于事件或延迟的处理？

什么是快：什么是更快的基于事件或延迟的处理？

Event.once('some_event', function() { // wait until an event fired from somewhere 
    defer.resolve('resolved') 
}) 
... 
// somewhere else 
Event.emit('some_event')

或smth.like：

defer = doSmthDeferred(); // to get the deferred resolved/rejected from somewhere else 
... 
// somewhere else 
doSmthDeferred = function() { 
    defer 
    if ... 
    defer.resolve(); 
    else 
    defer.reject(); 
}

即：什么是更好 - 事件处理或嵌套的承诺/ deferreds处理？是基于事件处理的承诺/延期？

来源

2013-03-09 static

这几乎是一个红色的鲱鱼。事件和承诺解决之间的速度差异几乎总是很小。

事件是为发生很多次的事情而设计的。例如请求到达Web服务器或用户单击按钮。当你将它们用于异步操作时，它们会变得杂乱无章，因为它们不能正确地支持组合，即，很难等待两个事件都发生承诺是专为异步操作（如从服务器请求网页）。他们只能解决一次，所以不适合举办类似事件。如果您有多个并行或串行的异步操作，承诺使得编写它们非常容易。如果你正在寻找一个很好的承诺库，我建议你退房Q

来源

2013-03-09 13:29:15 ForbesLindesay

谢谢！构图属性很好知道，在承诺中真的很有特色。我现在设计一个关于锁定/排队消息的小项目的模块，并且我无法克服这个问题，只能采用一种风格：基于承诺，所以有一个地方需要发出一个事件（当一个元素被解锁时，我需要通知队列将锁授予队列中的另一个元素，其中队列具有此事件的触发器）。那么通常还是应该只做一种风格？你怎么想？ – static 2013-03-10 05:25:23

一般而言，适当地混合和匹配两种风格是很好的。尽管如此，尝试并向外界展示一致的界面。如果你觉得你需要同时看到外部世界，你应该写两个单独的模块，每个模块都做一半的东西。在内部，对于你所描述的，你可能不想要一个完整的事件系统，你可能只想定义一个函数'processQueue'，并在元素解锁时调用'processQueue'。 – ForbesLindesay 2013-03-12 17:13:34

什么是更快的基于事件或延迟的处理？

回答

相关问题