Express - 在中间件函数之间传递数据的更好模式 [英] Express - better pattern for passing data between middleware functions

问题描述

我刚用Express提出了这个问题，我对StackOverflow对它的看法感兴趣：

I just brought up this issue with Express and I am interested in what StackOverflow thinks about it:

https://github.com/strongloop/express/issues/2831

my问题是为什么Express选择禁止开发人员在中间件函数之间直接传递数据，并且基本上迫使你将临时数据分配给请求对象，我一直认为这是一个非常尴尬的任务。

my question is why Express opts to disallow the developer from passing data directly between middleware functions and basically forces you to assign temporary data to the request object in what I have always considered to be a quite awkward assignment.

更具体：

在中间件函数之间传递数据通常涉及这样做

passing data between middleware functions usually involves doing this

req.specialData = {}
next();

然而，如果可能的话，它可能会更容易和更高效（！）

however, it would be perhaps much easier and more performant (!) if this were possible

next(null,data);

或

function mySpecialMiddleWare(req,res,next,data){}

//现在，调用上面的函数

//now, call the above function

mySpecialMiddleWare(req,res,next, {some:data});

问题是Express使用的，我认为是，通过检查function.length> 3或function.length === 4 ...

the problem is that Express uses a, what I believe to be, stupid way of determining if the call is to a normal middleware function or the next error first middleware function, by checking to see if the function.length > 3 or function.length === 4...

我说的话有什么可能吗？

is there any chance what I am saying makes any sense?

不允许直接更好/更容易/更快/更强通过中间件函数传递数据而不是将数据笨拙地分配给req ??

wouldn't it be better/easier/faster/stronger to allow direct passing of data via middleware functions instead of assigning data awkwardly to req ??

或许Express已经具备此功能并且我只是被误导了？

perhaps Express already has this capability and I am just misinformed?

推荐答案

我的问题是为什么Express选择禁止开发人员直接在中间件函数之间传递数据，并且基本上强制您将临时数据分配给我一直认为这是一个相当尴尬的任务中的请求对象。

my question is why Express opts to disallow the developer from passing data directly between middleware functions and basically forces you to assign temporary data to the request object in what I have always considered to be a quite awkward assignment.

所以我认为A PI是鼓励大多数中间件模块化，可重用和松散耦合的方式。这意味着通常应该做一些事情，而不必过多关注其他中间件可能在它们之前或之后运行的内容。为了实现这一目标并创建一个松散兼容的中间件功能的生态系统，express使API保持相当通用。这有利有弊。但是作为第一个问题的直接答案，我会说保持界面简单，一致和灵活，并尽量避免严格的顺序依赖。

So I think the API is the way it is to encourage most middleware to be modular, re-usable, and loosely coupled. That means the generally should do something without being concerned too much about what other middleware might run before them or after them. In order to achieve this and create an ecosystem of loosely-compatible middleware functions, express keeps the API fairly generic. There are pros and cons to this. But as a direct answer to your first question, I would say to keep the interface simple, consistent, and flexible as well as try to avoid strict ordering dependencies.

在您的情况下，中间件之间可能存在隐式依赖关系。另一个常见示例通常是您的会话中间件具有您的cookie中间件在其之前运行的隐式依赖。拥有这些都是隐含的可以被认为是创建错误和不必要的故障排除。另一方面，它使应用程序开发人员能够更轻松地混合和匹配可能彼此没有意识的中间件。

As in your case, there might be implicit dependencies between middlewares. Another common example would be typically your session middleware has an implicit dependency that your cookie middleware runs before it. Having these all be implicit can be argued to create bugs and unnecessary troubleshooting. On the other hand, it enables application developers to more easily mix and match middlewares that might otherwise have no awareness of one another.

事后我认为我和我一样一些快速维护者会同意，出于语义API的原因，使用函数arity（预期参数的数量）是TJ的一个奇怪和糟糕的选择。我认为如果要重写项目，将为错误处理定义更明确的API。

In hindsight I think both I as well as some of the express maintainers would agree that using function arity (number of expected arguments) for semantic API reasons was an odd and poor choice on TJ's part. I think if the project were to be rewritten a more explicit API would be defined for error handling.

不会更好/更容易/更快/更强，允许通过中间件函数直接传递数据，而不是将数据笨拙地分配给req ??

wouldn't it be better/easier/faster/stronger to allow direct passing of data via middleware functions instead of assigning data awkwardly to req ??

更好 - 这是高度的可论证的和基于意见的。它的简单性有很多可以说的，证据是巨大的生态系统和使用。还有其他可用的选择，例如hapi，restify等，但你可能会考虑它们。

Better - this is highly arguable and opinion based. There is a lot to be said for the simplicity of it and the evidence is the huge ecosystem and usage. There are alternatives available such as hapi, restify, etc, though so you might consider them.

更容易 - 可能不是。什么是非常容易的。

Easier - probably not. What's there is pretty easy.

更快 - 可能没有任何有意义的方式。不确定为什么你认为你的版本会更快，但最好在你做出这样的声明时带上指标。

Faster - probably not in any meaningful way. Not sure why you think your version would be faster, but best to bring metrics when you make such claims.

更强 - 如果更强你的意思是更明确的可能是的，但是有一些人仍然喜欢使用JavaScript，尽管TypeScript在Haskell中一直存在并且在某种意义上肯定是更强。

Stronger - If by "stronger" you mean more explicit that's probably true but there's a reason some people still prefer JavaScript even though TypeScript all the way up through Haskell exist and are definitely "stronger" in some sense of the word.

这篇关于Express - 在中间件函数之间传递数据的更好模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！