Tag: 事件驱动

编写可维护的事件驱动代码

我最近刚刚开始使用事件驱动的体系结构，来自一个非常标准的面向对象的思维模式。 我注意到的第一件事是，通过程序理解和追踪的难度似乎随着程序的规模成倍地增加。 虽然小型宠物项目很容易遵循，但感觉就像代码将迅速转向意大利面。 我明白，我对这种发展思维是陌生的，并不是我所有的面向对象的担忧都会继续下去。 在编写可维护，可理解的事件驱动代码方面是否有任何资源？ 使用node.js或Twisted或Event Machine的人对此做了什么？

Node.js的事件驱动有什么不同？ 我们不能在ASP.Net的HttpAsyncHandler中做到这一点吗？

我在networking编程方面并不是很有经验，而且我也没有在Node.js中编写任何代码，只是对事件驱动的方法感到好奇。 这看起来不错。 文章解释了当我们使用基于线程的方法来处理请求时可能发生的一些不好的事情，而应该select事件驱动的方法。 在基于线程的情况下，收银员/线程与我们卡在一起，直到我们的食物/资源准备就绪。 在事件驱动下，收银员会将我们发送到请求队列中的某个地方，这样我们就不会在等待我们的食物时阻止其他请求。 要扩展基于线程的阻塞，您需要增加线程的数量。 对我来说，这似乎是不正确地使用线程/线程池的一个不好的借口。 不能正确处理使用IHttpAsyncHandler？ ASP.Net接收一个请求，使用ThreadPool并运行处理程序（BeginProcessRequest），然后在里面我们用一个callback加载文件/数据库。 该线程应该可以自由处理其他请求。 一旦文件读取完成，ThreadPool就会被再次调用并执行剩下的响应。 对我来说不是那么不同，为什么这不是可扩展的？ 我所知道的基于线程的一个缺点是，使用线程需要更多的内存。 但只有这些，你才能享受到多核的好处。 我怀疑Node.js根本没有使用任何线程/内核。 所以，基于事件驱动和基于线程的（不要带“因为它是Javascript和每个浏览器…”的说法），有人可以指出使用Node.js的实际好处，而不是现有的技术？ 这是一个长期的问题。 谢谢 ：）