[译] Express 应用结构的最佳实践
前言
Node
和Express
并不严格要求它的应用的文件结构。你可以以任意的结构来阻止你的web应用。这对于小应用来说,通常是不错的,十分易于学习和实验。
但是,当你的应用在体积和复杂性上都变得越来越高时,情况就变得复杂了。你的代码可能会变得凌乱。当你的团队人数增加时,向在同一个代码库内写代码变得愈发困难,每次合并代码时都可能会出现各种各样的冲突。为应用增加新的特性和处理新的情况可能都会改变文件的结构。
一个好的文件结构,应该是每一个不同的文件或文件夹,都分别负责处理不同的任务。这样,在添加新特性时才会变得不会有冲突。
最佳实践
这里所推荐的结构是基于MVC设计模式的。这个模式在职责分离方面做得非常好,所以让你的代码更具有可维护性。在这里我们不会去过多地讨论MVC的优点,而是更多地讨论如果使用它来建立你的Express
应用的文件结构。
例子:
让我们来看下面这个例子。这是一个用户可以登录,注册,留下评论的应用。以下是他的文件结构。
1 | project/ |
这看上去可能有点复杂,但不要担心。在读完这篇文章之后,你将会完完全全地理解它。它本质上是十分简单的。
以下是对这个应用中的根文件(夹)的作用的简介:
- controllers/ – 定义你应用的路由和它们的逻辑
- helpers/ – 可以被应用的其他部分所共享的代码和功能
- middlewares/ – 处理请求的
Express
中间件 - models/ – 代表了实现了业务逻辑的数据
- public/ – 包含了如图片,样式,
javascript
这样的静态文件 - views/ – 提供了供路由渲染的页面模板
- tests/ – 用于测试其他文件夹的代码
- app.js – 初始化你的应用,并将所以部分联接在一起
- package.json – 记录你的应用的依赖库以及它们的版本
需要提醒的是,除了文件的结构本身,它们所代表的职责也是十分重要的。
Models
你应该在modules
中处理与数据库的交互,里面的文件包含了处理数据所有方法。它们不仅提供了对数据的增,删,改,查方法,还提供了额外的业务逻辑。例如,如果你有一个汽车model
,它也应该包含一个mountTyres
方法。
对于数据库中的每一类数据,你都至少应该创建一个对应的文件。对应到我们的例子里,有用户以及评论,所以我们至少要有一个user model
和一个comment model
。当一个model
变得过于臃肿时,基于它的内部逻辑将它拆分成多个不同的文件通常是一个更好的做法。
你应该保持你的各个model
之间保持相对独立,它们应相互不知道对方的存在,也不应引用对方。它们也不需要知道controllers
的存在,也永远不要接受HTTP请求和响应对象,和返回HTTP错误,但是,我们可以返回特定的model
错误。
这些都会使你的model
变得更容易维护。由于它们之间相互没有依赖,所以也容易进行测试,对其中一个model
进行改变也不会影响到其他model
。
以下是我们的评论model
:
1 | var db = require('../db') |
它并不引用用户model
。它仅仅需要一个提供用户信息的user
参数,可能包含用户ID或用户名。评论model
并不关心它到底是什么,它只关心这可以被存储。
1 | var db = require('../db') |
除了创建和管理用户的方法,用户的model
还应该提供身份验证和密码管理的方法。再次重申,这些model
之间必须相互不知道对方的存在。
Views
这个文件夹内包含了所有你的应用需要渲染的模板,通常都是由你团队内的设计师设计的。
当选择模板语言时,你可能会有些困难,因为当下可选择的模板语言太多了。我最喜欢的两个模板语言是Jade
和Mustache
。Jade
非常擅于生成HTML
,它相对于HTML
更简短以及更可读。它对JavaScript
的条件和迭代语法也有强大的支持。Mustache
则完全相反,它更专注于模板渲染,而不是很关心逻辑操作。
写一个模板的最佳实践是,不要在模板中处理数据。如果你需要在模板中展示处理后的数据,你应该在controller
处理它们。同样地,多余的逻辑操作也应该被移到controller
中。
1 | doctype html |
Controllers
在这个文件夹里的是所有你定义的路由。它们处理web请求,处理数据,渲染模板,然后将其返回给用户。它们是你的应用中的其他部分的粘合剂。
通常情况下,你应该至少为你应用的每一个逻辑部分写一个路由。例如,一个路由来处理评论,另一个路由来处理用户,等等。同一类的路由最好有相同的前缀,如/comments/all
,/comments/new
。
有时,什么代码该写进controller
,什么代码该写进model
是容易混淆的。最佳的实践是,永远不要在controller
里直接调用数据库,应该使用model
提供方法来代替之。例如,如果你有一个汽车model
,然后想要在某辆车上安上四个轮子,你应该直接调用db.update(id, {wheels: 4})
,而是应该调用类似car.mountWheels(id, 4)
这样的model
方法。
以下是关于评论的controller
代码:
1 | var express = require('express') |
通常在controller
文件夹中,有一个index.js
。它用来加载其他的controller
,并且定义一些没有常规前缀的路由,如首页路由:
1 | var express = require('express') |
这个文件的router
加载了你的所有路由。所以你的应用在启动时,只需要引用它既可。
Middlewares
所有的Express
中间件都会保存在这个文件夹中。中间件存在的目的,就是提取出一些controller
中,处理请求和响应对象的共有的代码。
和controller
一样,一个middleware
也不应该直接调用数据库方法。而应使用model
方法。
以下例子是middlewares/users.js
,它用来在请求时加载用户信息。
1 | User = require('../models/user') |
这个middleware
使用了用户model
,而不是直接操作数据库。
下面,是一个身份认证中间件。通过它来阻止未认证的用户进入某些路由:
1 | module.exports = function(req, res, next) { |
它没有任何外部依赖。如果你看了上文controller
中的例子,你一定已经明白它是如何运作的。
Helpers
这个文件夹中包含一些实用的工具方法,被用于model
,middleware
或controller
中。通常对于不同的任务,这些工具方法会保存在不同的文件中。
Public
这个文件只用于存放静态文件。通常是css
, 图片,JS库(如jQuery
)。提供静态文件的最佳实践是使用Nginx
或Apache
作为静态文件服务器,在这方面,它们通常比Node
更出色。
Tests
所有的项目都需要有测试,你需要将所有的测试代码放在一个地方。为了方便管理,你可能需要将这些测试代码放于几个不同的子文件夹中。
- controllers
- helpers
- models
- middleware
- integration
- ui
controllers
,helpers
,models
和middlewares
都十分清晰。这些文件夹里的文件都应该与源被测试的文件夹中的文件一一对应,且名字相同。这样更易于维护。
在上面这四个文件夹中,主要的测试代码将是单元测试,这意味着你需要将被测试的代码与应用分离开来。但是,integration
文件夹内的代码则主要用来测试你的各部分代码是否被正确得粘合。例如,是否在正确的地方,调用了正确的中间件。这些代码通常会比单元测试更慢一些。
ui
文件夹内包含了则是UI测试,它与integration
文件夹内的测试代码相似,因为它们的目标都是保证各个部分被正确地粘合。但是,UI测试通常运行在浏览器上,并且还需要模拟用户的操作。所以,通常它比集成测试更慢。
在前四个文件夹的测试代码,通常都需要尽量多包含各种边际情况。而集成测试则不必那么细致,你只需保证功能的正确性。UI测试也一样,它也只需要保证每一个UI组件都正确工作即可。
Other files
还剩下app.js
和package.json
这两个文件。
app.js
是你应用的起始点。它加载其他的一切,然后开始接收用户的请求。
1 | var express = require('express') |
package.son
文件的主要目的,则是记录你的应用的各个依赖库,以及它们的版本号。
1 | { |
你的应用也可以通过正确地配置package.json
,然后使用npm start
和nam test
来启动和测试你的代码。详情参阅:http://browsenpm.org/package.json
最后
原文链接:https://www.terlici.com/2014/08/25/best-practices-express-structure.html
原文作者: DavidCai
原文链接: https://davidc.ai/2015/11/19/译-Express应用结构的最佳实践/
许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议