我正在为NodeJS使用ExpressJS Web框架。
使用ExpressJS的人将他们的环境（开发，生产，测试…），路线等放置在app.js。我认为这不是一个好方法，因为当您拥有大型应用程序时，app.js太大了！
app.js
我想要这个目录结构：
| my-application | -- app.js | -- config/ | -- environment.js | -- routes.js
这是我的代码：
var express = require('express'); var app = module.exports = express.createServer(); require('./config/environment.js')(app, express); require('./config/routes.js')(app); app.listen(3000);
config / environment.js
module.exports = function(app, express){ app.configure(function() { app.use(express.logger()); }); app.configure('development', function() { app.use(express.errorHandler({ dumpExceptions: true, showStack: true })); }); app.configure('production', function() { app.use(express.errorHandler()); }); };
config / routes.js
module.exports = function(app) { app.get('/', function(req, res) { res.send('Hello world !'); }); };
我的代码运行良好，我认为目录的结构很漂亮。但是，必须对代码进行修改，但我不确定代码是否良好/美观。
使用我的目录结构并修改代码还是仅使用一个文件（app.js）更好？
感谢您的建议！
好的，已经有一段时间了，这是一个很普遍的问题，所以我继续前进，创建了一个带有JavaScript代码的脚手架github存储库，以及关于我喜欢如何构造一个中型express.js应用程序的自述文件。
focusaurus / express_code_structure是具有最新代码的存储库。拉请求欢迎。
这是自述文件的快照，因为stackoverflow不喜欢仅链接的答案。我将进行一些更新，因为这是我将继续更新的新项目，但是最终github存储库将是此信息的最新信息。
该项目是如何组织中型express.js Web应用程序的示例。
当前至少要表达v4.14 2016年12月
Web应用程序并不完全相同，在我看来，没有一个单一的代码结构可以应用于所有express.js应用程序。
如果您的应用程序很小，则不需要此处示例的深层目录结构。只需保持简单，然后将少量.js文件粘贴到存储库的根目录即可。Voilà。
.js
如果您的应用程序很大，则有时需要将其分解为不同的npm软件包。通常，node.js方法似乎倾向于使用许多小软件包，至少对于库而言是如此，并且您应该通过使用几个npm软件包来构建应用程序，因为这开始变得有意义并证明了开销。因此，随着应用程序的增长以及部分代码在应用程序外部或作为清晰的子系统可以清楚地重用，请将其移至其自己的git存储库中，并将其放入独立的npm包中。
因此 ，该项目的重点是说明中型应用程序的可行结构。
构建Web应用程序的方法有很多，例如
所有这些都很好地适合于不同的目录结构。就本示例而言，它只是脚手架，而不是一个完全正常运行的应用程序，但我假设以下关键体系结构要点：
在整个项目中，将成为一个主题，Ruby on Rails所体现的许多想法及其采纳的“ Convention over Configuration”决策尽管被广泛接受和使用，但实际上并没有什么帮助，有时与该存储库相反推荐。
我在这里的主要观点是，组织代码具有一些基本原则，基于这些原则，Ruby on Rails约定（大多数情况下）对Ruby on Rails社区有意义。但是，仅仅不加思索地修改这些约定就没有意义。一旦掌握了基本原理，您的所有项目都将井井有条，清晰：shell脚本，游戏，移动应用程序，企业项目，甚至您的主目录。
对于Rails社区，他们希望能够有一个Rails开发人员从一个应用程序切换到另一个应用程序，并且每次都熟悉并感到满意。如果您是37个信号机或Pivotal Labs，这非常有意义，并且有好处。在服务器端JavaScript世界中，总体上讲，风风雨雨更像西方，我们对此并不存在任何问题。我们就是这样滚动的。我们已经习惯了。即使在express.js中，它也是Sinatra的近亲，而不是Rails，并且从Rails获得约定通常无济于事。我什至要说 原则胜于约定胜于配置 。
app/node_modules
package.json
app
cd
kebab-case
camelCase
-
app/views
app/controllers
app/models
routes.rb
app/users
app/server.js:1
magicRESTRouter.route(somecontroller, {except: 'POST'})
app.get
app.put
app.del
使用小写字母的文件名
不要使用app.configure。它几乎完全没有用，您只是不需要它。由于盲目复制，它在很多样板中。
app.configure
紧急情况下中途和路线的顺序！！！
app.use
body-parser
server.js
社区在针对Node.js的更好的本地更好的require（）路径中概述并讨论了许多方法。我可能很快会决定选择“只处理大量的../../../ ..”还是使用requireFrom模块。但是，此刻，我一直在使用下面详述的symlink技巧。
因此，避免require("../../../config")使用类似恼人的相对路径来避免项目内需求的一种方法是使用以下技巧：
require("../../../config")
.gitignore
var config = require("app/config");
var DealModel = require("app/deals/deal-model")
通常，代码模块和类仅希望options传入基本JavaScript 对象。仅app/server.js应加载app/config.js模块。从那里可以options根据需要合成小对象以配置子系统，但是将每个子系统耦合到一个充满额外信息的大型全局配置模块上，则是不好的结合。
options
app/server.js
app/config.js
尝试集中创建数据库连接并将其传递到子系统中，而不是传递连接参数并让子系统自己进行传出连接。
这是Rails提出的另一个诱人但可怕的想法。您的应用中应该恰好有1个位置，app/config.js它可以查看NODE_ENV环境变量。其他所有内容都应采用显式选项作为类构造函数参数或模块配置参数。
NODE_ENV
如果电子邮件模块具有关于如何传递电子邮件的选项（SMTP，登录到stdout，放入队列等），则应采用类似的选项，{deliver: 'stdout'}但绝对不要选中NODE_ENV。
{deliver: 'stdout'}
现在，我将测试文件与其对应的代码保存在同一目录中，并使用文件扩展名命名约定将测试与生产代码区分开。
foo.js
foo.tape.js
foo.btape.js
我使用文件系统全局文件和find . -name '*.tape.js'命令来根据需要访问所有测试。
find . -name '*.tape.js'
这个项目的范围主要是关于文件和目录的位置，我不想添加其他范围，但是我只想提到我将代码分为3个不同的部分。
