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

Far*_*ina 5 javascript connect node.js express solid-principles

我开始学习 Node.js 并试图了解它与微框架 Express 相结合的架构。

我看到 Express 使用 Connect 作为中间件。Connect 使用一系列函数中的各种内容来扩充请求和响应对象,并且它提供了一个 API,因此您可以添加自定义中间件。我想这种扩充是一种在处理程序/控制器中保持简单和灵活的方法,而不是具有可变数量的参数和参数类型。下面是一个简单的 GET 处理程序示例:

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

在 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()
})
Run Code Online (Sandbox Code Playgroud)

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

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

dei*_*tch 6

这可以。恕我直言,该request对象的目的是作为一个容器,将事物向下传递堆栈供其他处理程序使用。这比寻找一些公认的全球持有者要干净得多。

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

事实上,几乎我见过的每个中间件,包括查看 express 源代码和我编写的中间件,都request用于这种“将属性和功能向下传递到处理程序堆栈的容器”。