Node.js项目的文件夹结构

gui*_* 桂林 332 node.js

我注意到Node.js项目通常包含这样的文件夹:

/ libs,/ vendor,/ support,/ spec,/ tests

这究竟是什么意思?它们之间有什么不同,我应该在哪里包含引用的代码?

sch*_*rmu 432

关于你提到的文件夹:

  • /libs 通常用于定制 classes/functions/modules
  • /vendor/support包含第三方库(使用git作为源代码控制时添加为git子模块)
  • /spec 包含BDD测试的规范.
  • /tests包含应用程序的单元测试(使用测试框架,请参见 此处)

注意:由于NPM引入了干净的包管理/vendor,/support因此不推荐使用和.建议使用NPM和package.json文件处理所有第三方依赖项

在构建一个相当大的应用程序时,我建议使用以下附加文件夹(特别是如果您使用某种类型的MVC-/ORM-Framework,如expressmongoose):

  • /models包含所有ORM模型(Schemas在mongoose中调用)
  • /views 包含您的视图模板(使用快递支持的任何模板语言)
  • /public 包含所有静态内容(图像,样式表,客户端JavaScript)
    • /assets/images 包含图像文件
    • /assets/pdf 包含静态pdf文件
    • /css 包含样式表(或由css引擎编译输出)
    • /js 包含客户端JavaScript
  • /controllers包含所有快速路由,由应用程序的模块/区域分隔(注意:当使用express的引导功能时,调用此文件夹/routes)

我习惯用这种方式组织我的项目,我觉得它很好用.

基于CoffeeScript的Express应用程序的更新(使用connect-assets):

  • /app 包含您编译的JavaScript
  • /assets/ 包含需要编译的所有客户端资产
    • /assets/js 包含客户端CoffeeScript文件
    • /assets/css 包含所有LESS/Stylus样式表
  • /public/(js|css|img) 包含任何编译器都不处理的静态文件
  • /src 包含所有服务器端特定的CoffeeScript文件
  • /test 包含所有单元测试脚本(使用您选择的测试框架实现)
  • /views 包含您所有的快递视图(无论是玉,ejs还是任何其他模板引擎)

  • 你会把你的客户端js,css,图像放在哪里?你会建议在公共文件夹中使用类似的文件夹结构,例如:public/assets public/assets/css public/assets/images public/assets/docs public/libs public/support public/tests public/models public/views public/controllers ? (5认同)
  • expressjs创建一个./routes目录,在你的例子中是否与./controllers相同? (2认同)
  • 你为什么不用这个提议创建一个Yeoman生成器?它可能成为一个标准. (2认同)

Pau*_*ira 47

有一个关于GitHub的讨论,因为有一个类似于这个的问题:https: //gist.github.com/1398757

您可以使用其他项目获取指导,在GitHub中搜索:

  • ThreeNodes.js - 在我看来,似乎有一个不适合每个项目的特定结构;
  • 打火机 - 结构更简单,但缺乏组织;

最后,在一本书(http://shop.oreilly.com/product/0636920025344.do)中建议这种结构:

  • 的index.html
  • JS /
    • main.js
    • 楷模/
    • 意见/
    • 收藏/
    • 模板/
    • 库/
      • 骨干/
      • 下划线/
      • ...
  • CSS /
  • ...

  • 为Github讨论+1,真的很酷! (13认同)

max*_*paj 16

假设我们正在讨论 Web 应用程序和构建 API:

\n

一种方法是按功能对文件进行分类。为了显示:

\n
\n

我们正在开发一个图书馆应用程序。在该应用程序的第一个版本中,用户可以:

\n
    \n
  • 搜索书籍并查看书籍的元数据
  • \n
  • 搜索作者并查看他们的书籍
  • \n
\n

在第二个版本中,用户还可以:

\n
    \n
  • 创建帐户并登录
  • \n
  • 借/借图书
  • \n
\n

在第三个版本中,用户还可以:

\n
    \n
  • 保存他们想读的书籍列表/标记为最爱
  • \n
\n
\n

首先我们有以下结构:

\n
books\n  \xe2\x94\x94\xe2\x94\x80 entities\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 book.js\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 author.js\n  \xe2\x94\x82\n  \xe2\x94\x94\xe2\x94\x80 services\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 booksService.js\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 authorsService.js\n  \xe2\x94\x82\n  \xe2\x94\x94\xe2\x94\x80 repositories\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 booksRepository.js\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 authorsRepository.js\n  \xe2\x94\x82\n  \xe2\x94\x94\xe2\x94\x80 controllers\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 booksController.js\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80 authorsController.js\n  \xe2\x94\x82\n  \xe2\x94\x94\xe2\x94\x80 tests\n      \xe2\x94\x94\xe2\x94\x80 ...\n
Run Code Online (Sandbox Code Playgroud)\n

然后我们添加用户和贷款功能:

\n
user\n  \xe2\x94\x94\xe2\x94\x80 controllers\n  \xe2\x94\x94\xe2\x94\x80 entities\n  \xe2\x94\x94\xe2\x94\x80 services\n  \xe2\x94\x94\xe2\x94\x80 ...\n\nloan\n  \xe2\x94\x94\xe2\x94\x80 controllers\n  \xe2\x94\x94\xe2\x94\x80 ...\n
Run Code Online (Sandbox Code Playgroud)\n

然后是收藏夹功能:

\n
favorites\n  \xe2\x94\x94\xe2\x94\x80 controllers\n  \xe2\x94\x94\xe2\x94\x80 entities\n  \xe2\x94\x94\xe2\x94\x80 ...\n
Run Code Online (Sandbox Code Playgroud)\n

对于任何新的开发人员来说,如果有任何一本书被标记为最喜欢的,那么书籍搜索还应该返回信息,很容易看出他/她应该在代码中的哪个位置查看。

\n

然后,当产品负责人突然介入并大声疾呼应该完全删除收藏夹功能时,删除它就很容易了。

\n


Dan*_*kov 12

从我的项目架构中可以看到更多示例:

??? Dockerfile
??? README.md
??? config
?   ??? production.json
??? package.json
??? schema
?   ??? create-db.sh
?   ??? db.sql
??? scripts
?   ??? deploy-production.sh 
??? src
?   ??? app -> Containes API routes
?   ??? db -> DB Models (ORM)
?   ??? server.js -> the Server initlializer.
??? test
Run Code Online (Sandbox Code Playgroud)

基本上,逻辑应用程序分离到SRC目录中的DB和APP文件夹.

  • @wal我更喜欢将前端项目分离到另一个存储库,因为它更有条理 (2认同)