这是我的建议,避免像火一样的全局状态。
- 根据我的经验,这是 Node 服务器中的头号维护问题。
- 它使您的代码不可组合并且更难重用。
- 它会在您的代码中创建隐式依赖关系——您永远无法确定哪一部分依赖于哪一部分,并且不容易验证。
您希望每个应用程序使用的代码部分尽可能明确。这是个大问题。
问题
我们希望跨多个请求同步状态并采取相应措施。这是编写软件的一个非常大的问题——有人说甚至是最大的问题。应用程序中对象通信方式的重要性不能被高估。
一些解决方案
有几种方法可以在 Node 服务器中实现跨请求或服务器范围的状态共享。这取决于你想做什么。这是两个最常见的imo。
- 我想观察请求的作用。
- 我希望一个请求根据另一个请求所做的事情来做事。
1.我想观察requests做了什么
同样,有很多方法可以做到这一点。这是我看到最多的两个。
这种方式请求发出事件。应用程序读取请求触发的事件并相应地了解它们。应用程序本身可以是您可以从外部观察到的事件发射器。
您可以执行以下操作:
request.emit("Client did something silly", theSillyThing);
如果你愿意的话,然后从外面听。
使用观察者模式
这就像一个事件发射器,但相反。您保留请求的依赖项列表,并在请求发生有趣的事情时自己调用处理程序方法。
就个人而言,我通常更喜欢事件发射器,因为我认为它们通常能更好地解决问题。
2. 我希望一个请求根据另一个请求所做的事情来做事。
这比只听要复杂得多。同样,这里有几种方法。他们的共同点是我们将共享放在服务中
而不是拥有全局状态 - 每个请求都可以访问服务 - 例如,当您读取文件时通知服务并且当您想要读取文件的列表时 - 您询问服务。依赖项中的所有内容都是明确的。
该服务不是全局的,只是它的依赖项。例如,它可以协调资源和数据,是某种形式的Repository)。
好理论!现在我的用例呢?
对于您的情况,我有两种选择。这远非唯一的解决方案。
第一个选项:
- 每个模块都是一个事件发射器,每当它们读取文件时,它们都会发射一个事件。
- 一个服务监听他们所有的事件并保持计数。
- 请求可以显式访问该服务,并且可以查询它以获取文件列表。
- 请求通过模块本身而不是添加的服务执行写入。
第二种选择:
- 创建一个拥有 module1、module2 和 module3 副本的服务。(作品)
- 该服务根据模块的要求将操作委托给模块。
- 该服务保留自通过它发出请求以来访问的文件列表。
- 请求停止直接使用模块 - 改为使用服务。
这两种方法都有优点和缺点。可能需要一个更复杂的解决方案(这两个在实践中非常简单),其中服务被进一步抽象,但我认为这是一个好的开始。