Express 是目前 node 社区最主要的 Web 框架,前不久刚刚升级到了 4.0 版本。与 3.x 版本比,4.0 版本拥有一个全新设计的 Router 模块,开发者可以更方便的对 middleware 进行隔离与重用。
Express 3.x 时代的中间件 (middleware) 与控制器 (controller)
在 express 3.x 版本中,一个控制器往往不是业务逻辑的全部,中间件才是业务逻辑的大头。例如一个处理用户订单的服务,往往验证用户权限、读写数据库等主要逻辑工作都在中间件中就完成了,而控制器所做的大部分工作就是拼数据给视图 (view)。
一个标准的 URL 映射写法如下:
app.js 1 2 3 4 5 | // 这里是一些中间件,express 的常见写法 var A = require('./middlewares/A'); var B = require('./middlewares/B'); var C = require('./middlewares/C'); app.get('/books', A, B, C, require('./controllers/book').index); |
1 2 3 4 5 6 7 | exports.index = function (req, res) { var retA = req.A; // 中间件 A 的输出结果 var retB = req.B; // 中间件 B 的输出结果 var retC = req.C; // 中间件 C 的输出结果 // ... 其余程序逻辑 } // ... |
控制器与中间件的相互依赖关系是完全隐式的,不能通过代码分析来得到任何的保证。中间件的插入与控制器的代码被分离在了 app.js
与 controllers/book.js
两个文件中,不仅阅读起来不直观,修改起来也很容易出错。假如有一天团队的新同事修改了 book.js
去掉了中间件 C
的逻辑,但是忘记了修改 app.js
(这是一个非常容易犯的错误),那么 express 不会报任何错误,code review 也很难发现,因为这两处代码离得实在是太远了。
这种设计同时会导致测试非常困难,因为单独 require
一个控制器是毫无意义的,因为控制器本身不可能独立于中间件来执行。如果要测试控制器,要么在单元测试代码在控制器前里现场装配中间件,要么就 mock 请求通过中间件后的数据。无论哪种做法,都需要单元测试完全了解中间件与控制器的业务逻辑才可能实现,这样就增大了单元测试的难度。
一个解决方法是将二者的依赖关系倒置,把控制器模块写成一个接收 app
作为参数的函数,在函数内部装配中间件与控制器。代码如下:
1 | require('./controllers/book')(app); |
1 2 3 4 5 6 7 8 9 10 11 12 13 | var A = require('../middlewares/A'); var B = require('../middlewares/B'); var C = require('../middlewares/C'); module.exports = function (app) { app.get('/books', A, B, C, function (req, res) { var retA = req.A; // 中间件 A 的输出结果 var retB = req.B; // 中间件 B 的输出结果 var retC = req.C; // 中间件 C 的输出结果 // ... 其余程序逻辑 }); }; // ... |
这样做虽然提高了代码的内聚性,但是直接把 app
暴露给其它模块使得 app
有被滥用的风险,让二者从面向接口的松散耦合变成了直接操纵实例的强耦合。同时这种方案不仅没有提高可测试性,反而大大提高了单元测试的难度(想想现在都需要 mock 一个 app
了 T_T)。
为了更好的解决这个问题,Express 4.0 给出了更好的解决方式: express.Router
。
使用 express.Router
来组织控制器与中间件
express.Router
可以认为是一个微型的只用来处理中间件与控制器的 app
,它拥有和 app
类似的方法,例如 get
、post
、all
、use
等等。上面的例子使用 express.Router
可以修改为:
1 | app.use(require('./controllers/book')); |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | var router = require('express').Rouer(); // 新建一个 router var A = require('../middlewares/A'); var B = require('../middlewares/B'); var C = require('../middlewares/C'); // 在 router 上装备控制器与中间件 router.get('/books', A, B, C, function (req, res) { var retA = req.A; // 中间件 A 的输出结果 var retB = req.B; // 中间件 B 的输出结果 var retC = req.C; // 中间件 C 的输出结果 // ... 其余程序逻辑 }); // ... // 返回 router 供 app 使用 module.exports = router; |
通过 express.Router
,控制器与中间件的代码紧密的联系在一起,并且避免了传递 app
的潜在风险。同时,一个 router
就是一个完整的功能模块,不需要任何装配就可以执行。这一点对于单元测试来说非常简单。
express.Router
的其他特性
中间件重用
上面提到过,express.Router
可以认为是一个迷你的 app
,它拥有一个独立的中间件队列。这个特性可以用来共享一些常用的中间件,例如:
1 2 3 4 5 6 | // parseBook 是个中间件 app.get('/books/:bookId', parseBook, viewBook); app.get('/books/:bookId/edit', parseBook, editBook); app.get('/books/:bookId/move', parseBook, moveBook); app.get('/other_link', otherController); |
Express 4.0 的写法:
express 4.0 1 2 3 4 5 6 7 8 9 10 | var bookRouter = express.Router(); app.use('/books', bookRouter); bookRouter.use(parseBook); // 下面三个控制器都会经过 parseBook 中间件 bookRouter.get('/books/:bookId', viewBook); bookRouter.get('/books/:bookId/edit', editBook); bookRouter.get('/books/:bookId/move', moveBook); app.get('/other_link', otherController); // 不会经过 parseBook 中间件 |
这个例子中 bookRouter
使 parseBook
这个中间件得到了充分的重用。
搭建 rest-ful 服务
Code talks:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | var bookRouter = express.Router(); bookRouter .route('/books/:bookId?') .get(function (req, res) { // ... }) .put(function (req, res) { // ... }) .post(function (req, res) { // ... }) .delete(function (req, res) { // ... }) |
小节
express.Router
是 express 4.0 中我最喜欢的更新,我认为 express 4.0 的代码里应该尽量多使用 express.Router
来代替原先的 app.get
方式。原先 URL 路径、中间件、控制器三者的松散关系可以借由 express.Router
变得紧密,整个控制器变成了一个不依赖于任何外部实例的独立模块,更有利于模块的拆分(想想把网站的各个模块都拆成独立的 router 吧),同时对于测试也更加友好。
http://lostjs.com/2014/04/24/router-in-express-4/