其他分享
首页 > 其他分享> > 前后端项目结构规范性记录

前后端项目结构规范性记录

作者:互联网

前言

以前对这块并没有去具体了解,就是简单的了解了一些小demo的开发流程。这次对这块写个记录。


后端

分享一篇微信上的文章:《优秀的项目代码是怎样分层的》,这是来自B站一个Up主codesheep的文章。
接下里其实见得最多的就是阿里的这张图以及阿里的解释
image

图片解释

• 开放 API 层:可直接封装 Service 接口暴露成 RPC 接口;通过 Web 封装成 http 接口;网关控制层等。
• 终端显示层:各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染,JS 渲染,JSP 渲染,移
动端展示等。
• Web 层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。
• Service 层:相对具体的业务逻辑服务层。
• Manager 层:通用业务处理层,它有如下特征:
1) 对第三方平台封装的层,预处理返回结果及转化异常信息,适配上层接口。
2) 对 Service 层通用能力的下沉,如缓存方案、中间件通用处理。
3) 与 DAO 层交互,对多个 DAO 的组合复用。
• DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase、OB 等进行数据交互。
• 第三方服务:包括其它部门 RPC 服务接口,基础平台,其它公司的 HTTP 接口,如淘宝开放平台、支
付宝付款服务、高德地图服务等。
• 外部数据接口:外部(应用)数据存储服务提供的接口,多见于数据迁移场景中。

分层领域模型规约
• DO(Data Object):此对象与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。
• DTO(Data Transfer Object):数据传输对象,Service 或 Manager 向外传输的对象。
• BO(Business Object):业务对象,可以由 Service 层输出的封装业务逻辑的对象。
• Query:数据查询对象,各层接收上层的查询请求。注意超过 2 个参数的查询封装,禁止使用 Map 类
来传输。
• VO(View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象。

image
尽量对整个Maven工程结构进行分层拆分,增加工程的可扩展性,实现高内聚低耦合的开发要求。
例子:图中将工程拆分为一个父工程和三个子工程:
•CancerCenter:父工程,只有POM的约束,无具体业务代码。
•CancerCenter_Common:通用工程,最下层依赖,包含utils,model,exception等整个项目的公共模块,提供整个项目的基础支撑。
•CancerCenter_Service:业务工程,向下依赖于Common,向上被Web依赖,包含service和mapper,是整个项目的核心业务。
•CancerCenter_Web:Web工程,向下依赖于Service,对外提供接口,包含接口、配置等Web项目独有的模块。


前端

├── build/                      # webpack 配置文件;
├── config/                     # 与项目构建相关的常用的配置选项;
│   ├── index.js                # 主配置文件
│   ├── dev.env.js              # 开发环境变量
│   ├── prod.env.js             # 生产环境变量
├── src/
│   ├── main.js                 # webpack 的入口文件,公共js文件;
│   ├── router.js               # webpack 的入口文件;
│   ├── assets/               	#资源目录;
│   ├── components/               #组件目录;
│   ├── store/               	#vuex目录;
│   ├── ....			#页面级vue组件;
├── static/                       # 纯静态资源,该目录下的文件不会被webpack处理,
├── .babelrc                      # babel 的配置文件
├── .editorconfig                # 编辑器的配置文件;可配置如缩进、空格、制表类似的参数;
├── .gitignore                   # git的忽略配置文件
├── index.html                   # HTML模板
├── package.json                # npm包配置文件,里面定义了项目的npm脚本,依赖包等信息
├── pub.js                       # 发版脚本文件
└── README.md

1.资源路径编译规则
默认情况下,vue-loader 使用 css-loader 和 Vue 模版编译器自动处理样式和模版文件。在编译过程中,所有的资源路径例如 、background: url(...) 和 @import 会作为模块依赖。
路径的编译规则如下:
如果路径是绝对路径,会原样保留;
如果路径以 . 开头,将会被看作相对的模块依赖,并按照你的本地文件系统上的目录结构进行解析;
如果路径以 @ 开头,也会被看作模块依赖。如果你的 webpack 配置中给 @ 配置了 alias,这就很有用了。所有 vue-cli 创建的项目都默认配置了将 @ 指向 /src;

2.build目录和config目录
build 目录下存放的是 webpack 的配置文件;
config 目录下存放的是与项目构建相关的常用的配置选项、变量;
通常情况下,除非要配置 webpack 的 loader 或者 插件,否则,你应该优先尝试更改 config 目录下的文件;

3.src目录
根据项目结构的核心思想,src的目录结构将以业务功能划分。
注意事项:
I . 项目的业务代码应该从 src/app/ 目录开始;
II . src/common/ 的子目录中,在深度上的层级结构应该是尽量扁平的,不应该有很深的层级结构;如果 src/common/ 中的目录树 与 src/app/ 中的目录树在深度上有十分相似的层级结构,则就表示你应该重新考虑 src/common/ 中的资源是否是真的需要被共享的资源,被共享的资源的目录层级结构应该是尽可能扁平的;对于不必共享的资源,应该放在 src/app/ 下相应的目录结构中;
III . src文件或文件夹的组成分为3种。直接在src目录下的vue文件是工程内直接于业务相关页面文件;components文件夹下是组件文件;其他文件夹是一些活动和主业务耦合性不大的文件。

4.static目录
static目录可以添加任何资源,如:图片、代码 等等。不过工程内图片大多存放七牛,static/project.js存放公共函数

微信文章:https://mp.weixin.qq.com/s/mNWc2tJWZlxJkKQh-kNpVg;可以参考一下,做个简单的前端认识。
下图来自于该篇文章。
image


最后

平时没事可以看看《阿里开发手册》,有助于对Java项目的开发流程的认识以及对规范的认识,可以有个良好的开发习惯。

标签:src,配置文件,记录,规范性,前后,接口,js,webpack,目录
来源: https://www.cnblogs.com/yuyueq/p/15204929.html