如何构建 ExpressJS 应用程序？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

7 个月前已关闭。

社区7个月前审查了是否重新开放此问题，并将其关闭：

原始关闭原因未解决

Answer 1

好的，已经有一段时间了，这是一个很受欢迎的问题，所以我继续创建了一个带有 JavaScript 代码的脚手架 github 存储库，以及一个关于我如何构建中型express.js 应用程序的长自述文件。

focusaurus/express_code_struct 是包含最新代码的存储库。欢迎拉请求。

这是自述文件的快照，因为 stackoverflow 不喜欢只是一个链接的答案。我将进行一些更新，因为这是一个我将继续更新的新项目，但最终 github 存储库将成为此信息的最新位置。

---

#Express 代码结构

该项目是如何组织中型express.js Web 应用程序的示例。

当前至少为 Express v4.14 2016 年 12 月

有多大你的应用程序是？

Web 应用程序并不完全相同，而且在我看来，不存在应该应用于所有express.js 应用程序的单一代码结构。

如果您的应用程序很小，则不需要如此深的目录结构，如此处所示。只需保持简单并将一些 .js 文件粘贴到存储库的根目录中即可。瞧。

如果您的应用程序很大，在某些时候您需要将其分解为不同的 npm 包。一般来说，node.js 方法似乎有利于许多小包，至少对于库来说是这样，您应该使用多个 npm 包来构建应用程序，因为这开始有意义并证明开销是合理的。因此，随着您的应用程序的增长，并且代码的某些部分变得明显可以在应用程序之外重用或者是一个明确的子系统，请将其移动到自己的 git 存储库并将其放入独立的 npm 包中。

因此该项目的重点是演示中型应用程序的可行结构。

您的整体架构是什么

构建 Web 应用程序的方法有很多，例如

• 服务器端 MVC、Ruby on Rails
• 单页应用程序风格、MongoDB/Express/Angular/Node (MEAN)
• 具有某些形式的基本网站
• 模型/操作/Views/Events 风格为 MVC 已死，是时候继续前进了
• 以及许多其他当前和历史的内容

中的每一个都很好地适合不同的目录结构。就本示例而言，它只是脚手架，而不是一个完全工作的应用程序，但我假设以下关键架构点：

• 该网站有一些传统的静态页面/模板
• 网站的“应用程序”部分是作为单个应用程序开发的页面应用程序样式
• 应用程序向浏览器公开 REST/JSON 样式 API
• 应用程序对一个简单的业务域进行建模，在本例中，它是一个汽车经销商应用程序

那么 Ruby on Rails 又如何呢？

整个项目的一个主题是，Ruby on Rails 中体现的许多想法以及它们所采用的“约定优于配置”决策虽然被广泛接受和使用，但实际上并不是很有帮助，有时与此存储库的内容相反推荐。

我在这里的主要观点是，组织代码有一些基本原则，并且基于这些原则，Ruby on Rails 约定对于 Ruby on Rails 社区来说（大部分）是有意义的。然而，只是不假思索地模仿这些惯例就没有抓住要点。一旦您掌握了基本原则，您的所有项目都将组织良好且清晰：shell 脚本、游戏、移动应用程序、企业项目，甚至您的主目录。

对于 Rails 社区来说，他们希望能够让单个 Rails 开发人员在应用程序之间切换，并且每次都能熟悉并适应它。如果您是 37 个信号或 Pivotal Labs，这非常有意义，并且有好处。在服务器端 JavaScript 世界中，整体精神是更加狂野的西部风格，我们对此并没有真正的问题。我们就是这样滚动的。我们已经习惯了。即使在express.js中，它也是Sinatra的近亲，而不是Rails，并且从Rails中获取约定通常没有任何帮助。我什至会说原则优于约定优于配置。

基本原则和动机

• 精神上可控
  • 大脑一次只能处理和思考少量相关的事物。这就是我们使用目录的原因。它通过专注于小部分来帮助我们处理复杂性。
• 尺寸合适
  • 不要创建只有 1 个文件且 3 个目录下的“Mansion 目录”。您可以在 Ansible 最佳实践 中看到这种情况的发生，它让小项目羞愧地创建了 10 多个目录当 1 个目录包含 3 个文件时，容纳 10 个以上文件会更合适。您不会驾驶公共汽车去上班（除非您是公共汽车司机，但即使如此，您在工作时驾驶公共汽车也不是工作），因此不要创建不符合其中实际文件合理性的文件系统结构.
• 模块化但务实
  • 节点社区总体上偏爱小模块。任何可以完全从应用程序中分离出来的内容都应该提取到模块中以供内部使用或在 npm 上公开发布。但是，对于此处讨论的中型应用程序来说，这种开销可能会增加您的工作流程的乏味，而没有相应的价值。因此，当您有一些代码被分解但不足以证明完全独立的 npm 模块合理时，只需将其视为“原型模块”，并期望当它超过某个大小阈值时，它将被提取出来。
  • 一些人，例如 @hij1nx 甚至包含 app/node_modules 目录并具有proto-module 目录中的 package.json 文件可促进该转换并充当提醒。
• 易于找到代码
  • 考虑到需要构建的功能或需要修复的错误，我们的目标是开发人员能够轻松找到所涉及的源文件。
    • 名称有意义且准确
    • 糟糕的代码已被完全删除，而不是留在孤立文件中或只是被注释掉
• 易于搜索
  • 所有第一方源代码都在 app 目录中，因此您可以 cd 运行 find/grep/xargs/ag/ack/etc 而不会分心通过第三方匹配
• 使用简单明了的命名
  • npm 现在似乎需要全小写的包名称。我觉得这很糟糕，但我必须随大流，因此文件名应该使用 kebab-case ，即使 JavaScript 中的变量名称必须是camelCase，因为 - 是 JavaScript 中的减号。
  • 变量名称与模块路径的基本名称匹配，但将 kebab-case 转换为 camelCase
• 按耦合分组，而不是按函数分组
  • 这与 Ruby on Rails 的 app/views、app/controllers、app/models 等约定有很大不同< /里>
  • 功能被添加到完整堆栈中，因此我想专注于与我的功能相关的完整文件堆栈。当我向用户模型添加电话号码字段时，我不关心除用户控制器之外的任何控制器，也不关心除用户模型之外的任何模型。
  • 因此，该存储库的组织方式是让我构建功能所需的所有文件都位于同一位置，而不是编辑各自目录中的 6 个文件并忽略这些目录中的大量其他文件
  • 根据 MVC 的本质，用户视图耦合到用户控制器，而用户控制器又耦合到用户模型。因此，当我更改用户模型时，这 3 个文件通常会一起更改，但交易控制器或客户控制器是解耦的，因此不会涉及。这通常也适用于非 MVC 设计。
  • 仍然鼓励 MVC 或 MOVE 风格的解耦（即哪些代码进入哪个模块），但将 MVC 文件分散到同级目录中只是令人烦恼。
  • 因此，我的每个路线文件都有其拥有的部分路线。如果您想要概述应用程序中的所有路线，则 Rails 风格的 routes.rb 文件会很方便，但在实际构建功能和修复错误时，您只关心与您所在的部分相关的路线改变。
• 将测试存储在代码旁边
  • 这只是“通过耦合分组”的一个实例，但我想特别指出它。我编写了许多项目，其中测试位于名为“tests”的并行文件系统下，现在我已经开始将测试与其相应的代码放在同一目录中，我再也不会回去了。这更加模块化，更容易在文本编辑器中使用，并减少了许多“../../..”路径的废话。如果您有疑问，请在几个项目上尝试一下，然后自己决定。除此之外，我不会做任何事情来让您相信它更好。
• 减少与事件的交叉耦合
  • 很容易想到“好吧，每当创建新交易时，我想向所有销售人员发送一封电子邮件”，然后只需将用于发送这些电子邮件的代码放在创建交易的路径中即可。
  • 但是，这种耦合最终会将您的应用变成一个巨大的泥球。
  • 相反，DealModel 应该只触发“创建”事件，而完全不知道系统可能会执行哪些其他操作来响应该事件。
  • 当您以这种方式编码时，将所有与用户相关的代码放入 app/users 中变得更加可能，因为不存在到处都是耦合业务逻辑的老鼠巢，污染了代码的纯度。用户代码库。
• 代码流程可遵循
  • 不要做神奇的事情。不要从文件系统中的魔术目录自动加载文件。不要成为Rails。该应用从 app/server.js:1 启动，您可以按照代码查看它加载和执行的所有内容。
  • 不要为您的路线制作 DSL。不需要时不要进行愚蠢的元编程。
  • 如果您的应用太大，那么执行 magicRESRouter.route(somecontroller, { except: 'POST'}) 对您来说比 3 个基本的 app.get 是一个巨大的胜利>、app.put、app.del 等调用，您可能正在构建一个太大而无法有效运行的整体应用程序。着眼于大胜利，而不是将 3 个简单行转换为 1 个复杂行。
• 使用小写的文件名
  • 此格式可避免跨平台的文件系统区分大小写问题
  • npm 禁止在新包名称中使用大写字母，这可以很好地配合

express.js 的具体细节

• 配合得很好。 不要使用 app.configure。它几乎完全没用，你只是不需要它。由于无意识的复制，它出现在很多样板文件中。
• Express 中的中间件和路由的顺序很重要！！！
  • 我在 stackoverflow 上看到的几乎每个路由问题都是无序的 Express 中间件
  • 一般来说，您希望路线解耦，而不是过分依赖顺序
  • 如果您确实只需要 2 个路由的中间件，请不要在整个应用程序中使用 app.use（我正在看着您，body-parser）
  • 确保当一切都说完并完成后，您确实收到了以下命令：
    1. 任何超级重要的应用程序范围中间件
    2. 您的所有路线和各种路线中间件
    3. THEN 错误处理程序
• 遗憾的是，受 sinatra 启发，express.js 大多数情况下假设所有路由都在 server.js 中，并且它将是清楚它们是如何排序的。对于中型应用程序，将事物分解为单独的路由模块很好，但它确实引入了无序中间件的危险

应用程序符号链接技巧

社区在要点中详细概述和讨论了许多方法< a href="https://gist.github.com/branneman/8048520" rel="noreferrer">更好的 Node.js 本地 require() 路径。我可能很快就会决定选择“只处理大量 ../../../..”或使用 requireFrom 模块。然而，目前，我一直在使用下面详细介绍的符号链接技巧。

因此，避免项目内需要像 require("../../../config") 这样烦人的相对路径的一种方法是使用以下技巧：

• 在 node_modules 下为您的应用程序
  • cd node_modules && ln -nsf ../app
• 仅添加node_modules/app符号链接本身，而不是整个node_modules文件夹到git
  • git add -f node_modules/app
  • 是的，您的 .gitignore 文件中应该仍然有“node_modules”
  • 不，您不应该将“node_modules”放入您的 git 存储库中。有些人会建议您这样做。他们是不正确的。
• 现在您可以使用此前缀来请求项目内模块
  • var config = require("app/config");
  • var DealModel = require("app/deals/deal-model");
• 基本上，这使得项目内部的工作要求与外部 npm 模块的要求非常相似。
• 抱歉，Windows 用户，您需要坚持使用父目录相对路径。

配置

通常，编码模块和类只需要传入基本的 JavaScript options 对象。只有 app/server.js 应该加载 app/config.js模块。从那里它可以合成小的 options 对象来根据需要配置子系统，但是将每个子系统耦合到一个充满额外信息的大型全局配置模块是不良耦合。

尝试集中创建数据库连接并将其传递到子系统中，而不是传递连接参数并让子系统自己建立传出连接。

NODE_ENV

这是另一个从 Rails 继承下来的诱人但糟糕的想法。您的应用中应该有 1 个位置 app/config.js 来查看 NODE_ENV 环境变量。其他一切都应该采用显式选项作为类构造函数参数或模块配置参数。

如果电子邮件模块有一个关于如何发送电子邮件的选项（SMTP、登录到标准输出、放入队列等），它应该采用像 {deliver: 'stdout'} 这样的选项，但它绝对应该不检查NODE_ENV。

测试

现在，我将测试文件与其相应的代码放在同一目录中，并使用文件扩展名命名约定来区分测试和生产代码。

• foo.js 具有模块“foo”的代码
• foo.tape.js 具有针对 foo 的基于节点的测试，并且位于同一目录
• foo 中。 btape.js 可用于需要在浏览器环境中执行的测试，

我使用文件系统 glob 和 find 。 -name '*.tape.js' 命令可根据需要访问我的所有测试。

如何在每个 .js 模块文件中组织代码

该项目的范围主要是关于文件和目录的位置，我不想添加太多其他范围，但我只想提到我组织我的代码分为 3 个不同的部分。

1. CommonJS 的打开块需要调用状态依赖关系
2. 纯 JavaScript 的主代码块。这里没有 CommonJS 污染。不要引用导出、模块或要求。
3. CommonJS 的关闭块用于设置导出

Answer 2

更新（2013-10-29）：请参阅我的其他答案，其中根据大众的需求使用 JavaScript 而不是 CoffeeScript，以及样板 github 存储库和详细说明我对此主题的最新建议的详细自述文件。

配置

你所做的一切都很好。我喜欢在顶级 config.coffee 文件中设置自己的配置命名空间，并使用这样的嵌套命名空间。

#Set the current environment to true in the env object
currentEnv = process.env.NODE_ENV or 'development'
exports.appName = "MyApp"
exports.env =
  production: false
  staging: false
  test: false
  development: false
exports.env[currentEnv] = true
exports.log =
  path: __dirname + "/var/log/app_#{currentEnv}.log"
exports.server =
  port: 9600
  #In staging and production, listen loopback. nginx listens on the network.
  ip: '127.0.0.1'
if currentEnv not in ['production', 'staging']
  exports.enableTests = true
  #Listen on all IPs in dev/test (for testing from other machines)
  exports.server.ip = '0.0.0.0'
exports.db =
  URL: "mongodb://localhost:27017/#{exports.appName.toLowerCase()}_#{currentEnv}"

这对于系统管理员编辑来说是友好的。然后，当我需要某些东西（例如数据库连接信息）时，它是

require('./config').db.URL

路由/控制器，

我喜欢将路由保留在控制器中，并将它们组织在 app/controllers 子目录中。然后我可以加载它们并让他们添加他们需要的任何路线。

在我的 app/server.coffee Coffeescript 文件中，我这样做：

[
  'api'
  'authorization'
  'authentication'
  'domains'
  'users'
  'stylesheets'
  'javascripts'
  'tests'
  'sales'
].map (controllerName) ->
  controller = require './controllers/' + controllerName
  controller.setup app

所以我有这样的文件：

app/controllers/api.coffee
app/controllers/authorization.coffee
app/controllers/authentication.coffee
app/controllers/domains.coffee

例如，在我的域控制器中，我有一个像这样的 setup 函数。

exports.setup = (app) ->
  controller = new exports.DomainController
  route = '/domains'
  app.post route, controller.create
  app.put route, api.needId
  app.delete route, api.needId
  route = '/domains/:id'
  app.put route, controller.loadDomain, controller.update
  app.del route, controller.loadDomain, exports.delete
  app.get route, controller.loadDomain, (req, res) ->
    res.sendJSON req.domain, status.OK

视图

将视图放在 app/views 中已成为惯例。我是这样布置的。

app/views/layout.jade
app/views/about.jade
app/views/user/EditUser.jade
app/views/domain/EditDomain.jade

静态文件

进入public子目录。

Github/Semver/NPM

将 README.md markdown 文件放在 github 的 git repo 根目录中。

将带有语义版本号的 package.json 文件放入 NPM 的 git 存储库根目录中。

Answer 3

以下是 Peter Lyons 的逐字回答，根据其他几个人的要求，从 Coffeescript 移植到了 vanilla JS。彼得的回答非常干练，任何对我的答案投票的人也应该对他的答案投票。

---

配置

你所做的一切都很好。我喜欢在顶级 config.js 文件中设置自己的配置命名空间，并使用这样的嵌套命名空间。

// Set the current environment to true in the env object
var currentEnv = process.env.NODE_ENV || 'development';
exports.appName = "MyApp";
exports.env = {
  production: false,
  staging: false,
  test: false,
  development: false
};  
exports.env[currentEnv] = true;
exports.log = {
  path: __dirname + "/var/log/app_#{currentEnv}.log"
};  
exports.server = {
  port: 9600,
  // In staging and production, listen loopback. nginx listens on the network.
  ip: '127.0.0.1'
};  
if (currentEnv != 'production' && currentEnv != 'staging') {
  exports.enableTests = true;
  // Listen on all IPs in dev/test (for testing from other machines)
  exports.server.ip = '0.0.0.0';
};
exports.db {
  URL: "mongodb://localhost:27017/#{exports.appName.toLowerCase()}_#{currentEnv}"
};

这对于系统管理员编辑来说是友好的。然后，当我需要某些东西（例如数据库连接信息）时，它是

require('./config').db.URL

路由/控制器，

我喜欢将路由保留在控制器中，并将它们组织在 app/controllers 子目录中。然后我可以加载它们并让他们添加他们需要的任何路线。

在我的 app/server.js javascript 文件中，我这样做：

[
  'api',
  'authorization',
  'authentication',
  'domains',
  'users',
  'stylesheets',
  'javascripts',
  'tests',
  'sales'
].map(function(controllerName){
  var controller = require('./controllers/' + controllerName);
  controller.setup(app);
});

所以我有这样的文件：

app/controllers/api.js
app/controllers/authorization.js
app/controllers/authentication.js
app/controllers/domains.js

例如，在我的域控制器中，我有一个像这样的 setup 函数。

exports.setup = function(app) {
  var controller = new exports.DomainController();
  var route = '/domains';
  app.post(route, controller.create);
  app.put(route, api.needId);
  app.delete(route, api.needId);
  route = '/domains/:id';
  app.put(route, controller.loadDomain, controller.update);
  app.del(route, controller.loadDomain, function(req, res){
    res.sendJSON(req.domain, status.OK);
  });
}

视图

将视图放在 app/views 中已成为惯例。我是这样布置的。

app/views/layout.jade
app/views/about.jade
app/views/user/EditUser.jade
app/views/domain/EditDomain.jade

静态文件

进入public子目录。

Github/Semver/NPM

将 README.md markdown 文件放在 github 的 git repo 根目录中。

将带有 语义版本 编号的 package.json 文件放入 NPM 的 git 存储库根目录中。

Answer 4

我的问题是 2011 年 4 月提出的，已经很老了。在此期间，我可以改善 Express.js 的体验以及如何构建使用该库编写的应用程序。所以，我在这里分享我的经验。

这是我的目录结构：

├── app.js   // main entry
├── config   // The configuration of my applications (logger, global config, ...)
├── models   // The model data (e.g. Mongoose model)
├── public   // The public directory (client-side code)
├── routes   // The route definitions and implementations
├── services // The standalone services (Database service, Email service, ...)
└── views    // The view rendered by the server to the client (e.g. Jade, EJS, ...)

App.js

app.js 文件的目标是引导expressjs 应用程序。它加载配置模块、记录器模块、等待数据库连接……并运行 Express 服务器。

'use strict';
require('./config');
var database = require('./services/database');
var express = require('express');
var app = express();
module.exports = app;

function main() {
  var http = require('http');

  // Configure the application.
  app.configure(function () {
    // ... ... ...
  });
  app.configure('production', function () {
    // ... ... ...
  });
  app.configure('development', function () {
    // ... ... ...
  });

  var server = http.createServer(app);

  // Load all routes.
  require('./routes')(app);

  // Listen on http port.
  server.listen(3000);
}

database.connect(function (err) {
  if (err) { 
    // ...
  }
  main();
});

routes/

路由目录有一个 index.js 文件。它的目标是引入一种魔法来加载 routes/ 目录中的所有其他文件。这是实现：

/**
 * This module loads dynamically all routes modules located in the routes/
 * directory.
 */
'use strict';
var fs = require('fs');
var path = require('path');

module.exports = function (app) {
  fs.readdirSync('./routes').forEach(function (file) {
    // Avoid to read this current file.
    if (file === path.basename(__filename)) { return; }

    // Load the route file.
    require('./' + file)(app);
  });
};

使用该模块，创建新的路由定义和实现非常容易。例如，hello.js：

function hello(req, res) {
  res.send('Hello world');
}

module.exports = function (app) {
  app.get('/api/hello_world', hello);
};

每个路由模块都是独立的。

Answer 5

我认为这是一个很好的方法。不限于express，但我在github上看到很多node.js项目都在做同样的事情。他们取出配置参数+较小的模块（在某些情况下每个 URI）被分解到单独的文件中。

我建议您浏览 github 上的 Express 特定项目以获得一个想法。 IMO，你的做法是正确的。

Answer 6

我喜欢使用全局“应用程序”，而不是导出函数等

Answer 7

现在是2015 年底，经过 3 年的小型和大型项目开发我的结构。结论？

不要做一个大的MVC，而是将其分成模块

所以...

为什么？

• 通常一个模块适用于一个模块（例如产品），您可以更改该模块独立。

• 您可以重用模块

• 您可以单独测试它

• 您可以单独替换它

• 它们具有清晰（稳定）的接口

  - 最晚，如果有多个开发人员工作，模块分离会有所帮助

nodebootstrap 项目与我的最终结构有类似的方法。 (github)

这个结构是什么样的？

1. 小型封装模块，每个模块都有单独的 MVC

2. 每个模块都有一个 package.json

3. Testing 作为结构的一部分（在每个模块中）

4. 全局配置、库和服务

5. 集成 Docker、集群，永远

   >

文件夹概述（模块见 lib 文件夹）：

< /a>

Answer 8

我给出了 MVC 风格的文件夹结构，请在下面找到。

我们为大中型 Web 应用程序使用了以下文件夹结构。

 myapp   
|
|
|____app
|      |____controllers
|      |    |____home.js
|      |
|      |____models
|      |     |___home.js
|      |
|      |____views
|           |___404.ejs
|           |___error.ejs
|           |___index.ejs
|           |___login.ejs
|           |___signup.ejs
|   
|
|_____config
|     |___auth.js
|     |___constants.js
|     |___database.js
|     |___passport.js
|     |___routes.js
|
|
|____lib
|    |___email.js
|
|____node_modules
|
|
|____public.js
|    |____css
|    |    |__style.css
|    |    
|    |____js
|    |    |__script.js
|    |
|    |____img
|    |    |__img.jpg
|    |
|    |
|    |____uploads
|         |__img.jpg
|      
|   
|
|_____app.js
|
|
|
|_____package.json

我创建了一个 npm 模块来生成 Express Mvc 文件夹结构。

请找到下面的 https://www.npmjs.com/package/express-mvc-generator

只需简单的步骤即可生成和使用此模块。

i) 安装模块 npm installexpress-mvc-generator -g

ii) 检查选项 express -h

iii) 生成express mvc 结构 express myapp

iv ) 安装依赖项： npm install:

v)打开 config/database.js ，请配置您的 mongo db。

vi) 运行应用程序 node app 或 nodemon app

vii) 检查 URL http ://localhost:8042/signup 或 http://yourip:8042/signup

Answer 9

我不认为将路由添加到配置中是一个好方法。更好的结构可能是这样的：

application/
| - app.js
| - config.js
| - public/ (assets - js, css, images)
| - views/ (all your views files)
| - libraries/ (you can also call it modules/ or routes/)
    | - users.js
    | - products.js
    | - etc...

因此 products.js 和 users.js 将包含所有路由以及其中的所有逻辑。

Answer 10

自从上次回答这个问题以来已经有一段时间了，Express 最近还发布了版本 4，它添加了一些用于组织应用程序结构的有用内容。

下面是一篇长篇最新博客文章，介绍如何构建 Express 应用程序的最佳实践。
http://www.terlici.com/2014/08 /25/best-practices-express-struct.html

还有一个 GitHub 存储库应用了本文中的建议。它始终与最新的 Express 版本保持同步。
https://github.com/terlici/base-express

Answer 11

好吧，我把我的路线作为一个 json 文件，我在开始时阅读该文件，并在 app.js 的 for 循环中设置路线。 Route.json 包含应调用的视图以及将发送到路由中的值的键。
这适用于许多简单的情况，但我必须为特殊情况手动创建一些路由。

Answer 12

我专门写了一篇文章来讨论这个问题。它基本上利用了一个 routeRegistrar 来循环访问文件夹 /controllers 中的文件，调用其函数 init。函数 init 将express app 变量作为参数，以便您可以按照您想要的方式注册路线。

var fs = require("fs");
var express = require("express");
var app = express();

var controllersFolderPath = __dirname + "/controllers/";
fs.readdirSync(controllersFolderPath).forEach(function(controllerName){
    if(controllerName.indexOf("Controller.js") !== -1){
        var controller = require(controllersFolderPath + controllerName);
        controller.init(app);
    }
});

app.listen(3000);

Answer 13

这可能会引起兴趣：

https://github.com/flatiron/nconf

包含文件、环境变量、命令行参数和原子对象合并的分层 Node.js 配置。

Answer 14

http://locomotivejs.org/ 提供了一种构建使用 Node.js 和 Express 构建的应用程序的方法。

来自网站：

“Locomotive是Node.js的Web框架。Locomotive支持MVC
模式、RESTful 路由和约定优于配置，同时
与任何数据库和模板引擎无缝集成。
Locomotive 以 Express 为基础，保留了强大功能和简单性
您已经对 Node 抱有期望了。”

Answer 15

1) 您的 Express 项目文件系统可能类似于：

/ ...
/lib
/node_modules
/public
/views
      app.js
      config.json
      package.json

app.js - 您的全局应用程序容器

2) 模块主文件 (lib/mymodule/index.js)：

var express = require('express');    
var app = module.exports = express();
// and load module dependencies ...  

// this place to set module settings
app.set('view engine', 'jade');
app.set('views', __dirname + '/views');

// then do module staff    
app.get('/mymodule/route/',function(req,res){ res.send('module works!') });

3) 在主 app.js 中连接模块

...
var mymodule = require('mymodule');
app.use(mymodule);

4) 示例逻辑

lib/login
lib/db
lib/config
lib/users
lib/verify
lib/
   /api/ 
   ...
lib/
   /admin/
      /users/
      /settings/
      /groups/
...

• 最适合测试
• 最适合规模
• 单独取决于模块
• 按功能（或模块）对路线进行分组

tj 在 Vimeo 上说/展示了如何模块化的有趣想法快速申请——
使用 Node.js 和 Express 的模块化 Web 应用程序。功能强大且简单。

Answer 16

我最近将模块视为独立的迷你应用程序。

|-- src
  |--module1
  |--module2
     |--www
       |--img
       |--js
       |--css
     |--#.js
     |--index.ejs
  |--module3
  |--www
     |--bower_components
     |--img
     |--js
     |--css
  |--#.js
  |--header.ejs
  |--index.ejs
  |--footer.ejs

现在，对于任何模块，路由 (#.js)、视图 (*.ejs)、js、css 和资产都彼此相邻。
子模块路由是在父 #.js 中设置的，并带有另外两行，

router.use('/module2', opt_middleware_check, require('./module2/#'));
router.use(express.static(path.join(__dirname, 'www')));

这样甚至可以使用子模块。

不要忘记将视图设置为 src 目录

app.set('views', path.join(__dirname, 'src'));

Answer 17

Sails.js 结构对我来说看起来又漂亮又干净，所以我在我的 Express 项目中使用 MVC 风格结构，类似于 sails.js。

project_root  
|  
|_ _ app  
|_ _ |_ _ controllers  
|_ _ |_ _ |_ _ UserController.js  
|_ _ |_ _ middlewares  
|_ _ |_ _ |_ _ error.js  
|_ _ |_ _ |_ _ logger.js  
|_ _ |_ _ models  
|_ _ |_ _ |_ _ User.js  
|_ _ |_ _ services  
|_ _ |_ _ |_ _ DatabaseService.js  
|  
|_ _ config  
|_ _ |_ _ constants.js  
|_ _ |_ _ index.js  
|_ _ |_ _ routes.js  
|  
|_ _ public  
|_ _ |_ _ css  
|_ _ |_ _ images  
|_ _ |_ _ js  
|  
|_ _ views  
|_ _ |_ _ user  
|_ _ |_ _ |_ _ index.ejs  

应用程序文件夹 - 包含应用程序的整体登录。
配置文件夹 - 包含应用配置、常量、路由。
公共文件夹 - 包含样式、图像、脚本等
视图文件夹 - 包含每个模型的视图（如果有）

可以在此处找到样板项目，
https://github.com/abdulmoiz251/node-express-rest-api-样板文件

Answer 18

这就是我的大部分 Express 项目目录结构的样子。

我通常会使用 express dirname 来初始化项目，请原谅我的懒惰，但它非常灵活且可扩展。 PS - 您需要为此获取 express-generator （对于那些正在寻找它的人 sudo npm install -gexpress-generator，sudo 因为您正在安装它全球范围内）

|-- bin
    |-- www //what we start with "forever"
|-- bower_components
|-- models
    |-- database.js
    |-- model1.js //not this exact name ofcourse.
    |-- .
|-- node_modules
|-- public
    |-- images
    |-- javascripts
        |-- controllers
        |-- directives
        |-- services
        |-- app.js
        |-- init.js //contains config and used for initializing everything, I work with angular a lot.
    |-- stylesheets
|-- routes
    |-- some
    |-- hierarchy
    .
    .
|-- views
    |-- partials
    |-- content
|-- .env
|-- .env.template
|-- app.js
|-- README.md

您一定想知道为什么是 .env 文件？因为他们工作！我在我的项目中使用了 dotenv 模块（最近经常使用）并且它有效！在 app.js 或 www 中弹出这 2 条语句

var dotenv = require('dotenv');
dotenv.config({path: path.join(__dirname + "/.env")});

，并在另一行中快速设置 /bower_components 以在资源 下提供静态内容/ext

app.use('/ext', express.static(path.join(__dirname, 'bower_components')));

它可能适合那些希望同时使用 Express 和 Angular 的人，或者只是在没有 javascripts 层次结构的情况下进行表达的人。

Answer 19

我的结构表达4。
https://github.com/odirleiborgert/borgert-express-boilerplate

包

View engine: twig
Security: helmet
Flash: express-flash
Session: express-session
Encrypt: bcryptjs
Modules: express-load
Database: MongoDB
    ORM: Mongoose
    Mongoose Paginate
    Mongoose Validator
Logs: winston + winston-daily-rotate-file
Nodemon
CSS: stylus
Eslint + Husky

结构

|-- app
    |-- controllers
    |-- helpers
    |-- middlewares
    |-- models
    |-- routes
    |-- services
|-- bin
|-- logs
|-- node_modules
|-- public
    |-- components
    |-- images
    |-- javascripts
    |-- stylesheets
|-- views
|-- .env
|-- .env-example
|-- app.js
|-- README.md

Answer 20

构建 Express 应用程序的简单方法：

• 在主 index.js 中，应保持以下顺序。

  <块引用>

  所有app.set都应该放在第一位。

  所有app.use应该排在第二位。

  后跟其他 api 及其函数或在其他文件中继续路由

  示例

  app.use("/password",passwordApi);

  app.use("/user", userApi);

  app.post("/token", Passport.createToken);

  app.post("/logout", Passport.logout)

Answer 21

ExpressJs 项目的 MVC 结构的最佳方法护照

- app
      -config 
        -passport-setup.js
      -controllers
      -middleware
      -models
      -routes
      -service
    -bin
      -www
      -configuration.js
      -passport.js
    -node_modules
    -views
     -handlebars page
    -env
    -.gitignore
    -package.json
    -package-lock.json