事件驱动程序是否适合非图形应用程序?

这完全取决于您要完成的工作。 如果您有一个旨在监视和响应随机警报的系统,例如数据中心监视应用程序,那么您肯定可以使用事件驱动的编程。

另一个应用程序可能是监视股票价格并根据您正在监视的股票或基金的当前价格触发买卖订单。

但是,在某些应用程序中,事件驱动的编程不合适。 例如,如果您有一个制造小部件的工厂,则动作和响应都是顺序的。 甚至您的大多数警报都位于生产中的给定点,例如Picker A没有更多的零件。 在这种情况下,为应用程序的主要部分选择事件驱动的编程是不明智的。 但是,正如某些警报说的那样,诸如断断续续的断路器之类的事件可能是随机的,因此可能需要使用事件驱动的系统进行监视。

因此,对于使用JavaScript的前两种情况,这是一个有效的选择,但对于工厂要求的顺序处理和监视,它不是一个很好的选择,尽管不幸的是,我已经看到它用于此。

事件驱动程序非常适合需要对刺激做出反应的任何事情。

考虑一下Node,很快,我们为Web服务器提供了一个非常小,非常有用的核心:

var http = require(“ http”);
var server = http.createServer(/ *…* /);
server.on(“ request”,handleConnection);

函数handleConnection(请求,响应){
response.write(“你好,世界!”);
response.end();
}

server.listen(“ …”);

还有很多其他情况。 与坐下来轮询相比,当一切准备就绪时戳戳是管理异步复杂性的好方法。

无论是通过回调,期货/承诺,异步+等待,流,通道,发布订阅……但是您想要处理它…
这不是解决所有问题的模式(什么都没有),但确实可以减轻生活的难度。

它非常适用于实时嵌入式控制和网络领域。

在实时系统中,除了对传感器事件做出反应外,CPU几乎没有其他作用。 就像“按下启动按钮”和“达到正确的温度”。 然后,代码使执行器执行任务。 可能是“打开热水器”和“关闭热水器”。 诸如“温度过高”之类的警报条件也很容易形成事件。

类似于TCP或HTTP的网络是类似的。 收到数据包,可用连接等等都是不错的事件。

基于事件的系统绝对具有比GUI更广泛的适用性

实际上非常合适。 想想任何nodejs应用,nginx之类的Web服务器,消息队列,设备驱动程序,电子表格等。

这些只是我脑中浮现的一些例子,但是任何一种反应式编程都使用事件驱动模型。

这完全取决于您要构建的内容。 如果您要构建某种计算器,那么可能根本就没有。 但是也许您正在构建一个将目录中的文件索引到数据库中的应用程序。 好吧,您可能希望使代码在目录更改事件上运行。

语言,技术,模式和方法都需要通过您尝试构建的解决方案的上下文来证明。