“拉”/“推”编程范式的历史和应用领域

Question

最近阅读了大量关于反应性编程的材料，其中一件经常提到的是“推送”和“拉”式的应用程序。事件驱动(反应编程)

一些作者说，这两种样式都有各自的应用领域，但我们尝试建模的大多数应用领域在现实世界中都在快速变化，因此事件驱动更合适吗？

为什么我们从‘拉’的方法开始，现在变成‘推’的方法，有什么具体的原因导致这种变化？

Answer 1

即使在今天，也有一些区域，您必须提取数据，因为推送选项对您来说是不可用的。据我所知，这些系统已经存在了很长时间，所以早期的系统可能只是接受那些拉着的系统。

让我们从一个非常简单的例子开始:您希望监视硬盘上的文件夹，并在该文件夹中出现新文件时执行一些操作。在现代语言中，为您提供了允许您注册某种侦听器的抽象，一旦检测到文件，就会调用它。早些时候，当这些抽象不可用时，您必须自己检查，方法是不断地提取文件夹信息并检查是否有一个新文件。

虽然这听起来可能很老，但当您从一个简单的文件夹转到f.ex时，这个问题在现代环境中再次出现。源代码存储库。我们大多数人都有一个CI服务器，比如Jenkins正在运行，瞧，它怎么知道有人向项目的SVN存储库提交了一些东西？它每隔x分钟从回购程序中提取数据(或为拉间隔配置的任何内容)。和往常一样，我们可以投入一些精力来实现推式实现，但是您必须找到适用于所有代码存储库实现的东西，这毕竟不是那么简单。

最后，在嵌入式领域，拉法已经占据了很长一段时间，而且不会很快消失。当您拥有可以访问的简单硬件时，通常会不得不提取其数据并检查更改。只有较高级别的硬件元素，如CPU，才能提供抽象。然而，在最低的级别上，您只需要0和1，电源关闭或打开。

由于这个原因，我认为早期的软件开发(它仍然接近硬件级别)受到了从硬件元素中提取数据的影响。我仍然认识许多嵌入式程序员，他们仍在编写无休止的轮询循环，这些循环只需不断地获取最新的传感器数据，以便在发生足够大的变化时进行处理。因此，从这个角度来看，编写基于拉式的代码似乎很自然。

然而，我们过去所做的是在上面添加一个抽象层，这给我们提供了一个洞察力，即在许多方面，推送方法要好得多。因此，我们一直在寻找从一种转移到另一种的方法。人们意识到，如果一个文件夹手表可以实现，这样所有的观察者都可以通过推送式的方式得到通知，那么我们必须编写的软件就会变得更容易，从而更便宜，更快地上市。

要回答你关于合适性的问题:如果你已经有了一个可以使用的推式界面，那么它很可能是更好的选择。但在某些情况下，您还没有这样的接口，只剩下两个选项:要么自己创建抽象级别，要么直接采用拉式方法。一般情况下，适当性取决于你的实际情况和一些罕见的情况(见上文)，在这种情况下，你唯一可行的方法就是拉。