项目的组织就犹如行军作战的阵法和章法,混乱而无目的的军队几乎不可能打胜仗,有其形,有其魂的组织的生命周期才会更长,其形态才更稳固。
–《深入浅出Nodejs》

这一篇我们来聊聊结缘的项目结构。由于结缘是web应用,我们以常见的MVC为主要框架,然后在这个基础上进行扩展。结合卜灵的《深入浅出Nodejs》产品化一章中的应用项目结构以及之前做的项目的一些经验,结缘的目录结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
.
├── CHANGELOG.md //网站的变更历史
├── INSTALL.md // 安装说明
├── LICENSE // 遵循的网络协议
├── Makefile //Makefile 文件
├── README.md
├── api //提供给移动端调用的api逻辑,类似web端的controllers
├── app.js
├── benchmark //基准测试
├── bin //可执行文件目录
├── config //设置文件目录
├── controllers //控制器
├── dispatch.js //多进程管理
├── libs //没有模块化得文件目录
├── logs //存放log信息
├── middlewares //中间件
├── models //数据库模型文件
├── node_modules // nodejs库
├── npm-debug.log // 忽略,npm的log文件
├── package.json //描述文件,依赖配置
├── proxy // 数据代理目录
├── public //静态文件目录
├── routes //路由处理目录
├── routes.js // 路由注册文件
├── test //测试文件目录
├── tools //工具文件目录
└── views // 视图目录
16 directories, 10 files

这里也没啥特别要注意的,这里的Makefile作为构建工具后面可能被gulp替代以实现更多定制和跨平台特性,models文件和传统的模型概念上不同,是用来描述数据库的Schema的,传统的模型和proxy更加接近,proxy提供对数据库数据的代理方法。