javascript - Node.js 和 Express - 增加请求对象是个好主意吗？

Question

我开始学习 Node.js 并尝试结合微框架 Express 来理解它的架构。

我看到 Express 使用 Connect 作为中间件。 Connect 在函数链中用各种东西扩充了请求和响应对象，它还提供了一个 API，因此您可以添加自定义中间件。我想这种扩充是一种在处理程序/ Controller 中保持简单和灵活的方法，而不是使用可变数量的参数和参数类型。这是一个简单的 GET 处理程序的示例:

app.get('/', function (req, res) {
    res.render('index', { title: 'Hey', message: 'Hello there!'});
})

在 Node.js 专家的教程中，我看到了诸如使用 MongoDB 集合扩充请求对象之类的内容。在来自 Azat Mardan 的博客中我看过这段代码:

var db = mongoskin.db('mongodb://@localhost:27017/test', {safe:true})

app.param('collectionName', function(req, res, next, collectionName){
   req.collection = db.collection(collectionName)
   return next()
})

上述方法使用路由名称中的“collectionName”参数作为条件来控制请求的增加。但是，我看到了更丑陋的代码，其中数据库中间件附加在每个通过 Node.js 的请求上，而没有这种条件方法。

看看单一责任原则、关注点分离和可测试性等标准软件原则，为什么用 MongoDB 集合对象和许多其他对象扩展请求是个好主意？请求和响应对象不会以这种方式因功能而膨胀并且具有不可预测的状态和行为吗？这种模式从何而来，优缺点和替代方案是什么？

Answer 1

这很好。恕我直言，request 对象的真正目的是作为一个容器，将事物向下传递到堆栈，供其他处理程序使用。这比寻找一些商定名称的全局持有者要干净得多。

您可能会争辩说它应该大部分是空的，然后在 request 的某些属性上具有“官方”request 和 response 功能>/response 对象，所以它更干净，但我认为好处很小。

事实上，几乎所有我见过的中间件，包括查看 express 源代码和我编写的代码，都使用 request 作为这种“向下传递属性和功能的容器”处理程序堆栈”。