约束

本规范仅适用于内部项目以及关联项目。内部项目皆受“业务”驱动，以“微应用”为核心单位。 “微应用”：指单例服务或单个微服务。

序号 类型 命名规范 说明 备注
1 变量 ${co} 微应用名称
2 变量 ${business} 业务名称
3 变量 ${type} 自定义类型名称
4 变量 ${time} 时间
5 符号 【变量】+？ 此变量非必需

数据库

主要参考《数据库MySQL设计规范》，其中规范2.2.c.1数据库对象命名规范略作变动：

  1. 所有表需要加 ${co} 作为前缀；例如：_cdthings_user（cdthings项目用户主表）
  2. 项目主业务，以 ${co}${business} 格式；例如：_tpms_plan（TPMS项目计划表）
  3. 定制化业务，以 ${co}${business}${type} 格式；例如：tpms_plan_detail_pfma（TPMS项目总装计划表）
  4. 字典表中需定义 ${type}翻译，需要时以供查找 | 序号 | 类型 | 命名规范 | 说明 | 备注 | | —- | —- | —- | —- | —- | | 1 | 主数据表 | ${co}${business} | 例如:author2uer，代表授权模块用户表；
    例如:tpms_plan_detail，代表tpms项目计划详情表 | | | 2 | 业务详情辅助数据表 | ${co}    ${business}${type} | 例如:tpms_plan_detail_pfma，代表tpms项目总装定制化计划详情表 | | | 3 | 关联中间表 | ${co}${business}tr | 例如:author2_user_role_tr，代表授权模块记录用户和角色的关系表 | | | 4 | 通用代码/字典表 | ${co}${business?}td | 例如:pmt_td，代表pmt项目的字典表;
    pmt_project_type_td，代表pmt项目的项目类型字典表 | | | 5 | 临时表 | ${co}    ${business}${type}_tmp | 例如:tpms_plan_detail_tmp，代表tpms项目计划详情临时表 | | | 6 | 备份表 | ${co}${business}${type}_bak | 例如:tpms_plan_detail_bak，代表tpms项目计划详情操作备份表 | | | 7 | 历史表 | ${co}${business}_${type}_th | 例如:tpms_plan_detail_th，代表tpms项目计划详情操作历史表 | | | 8 | 接口中间表 | ${co}_api | 例如:crm_api，代表crm项目接口表 | |

项目结构

  1. 包的命名：包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式，但是类名如果有复数含义，类名可以使用复数形式。
  2. 接口和实现类的命名规则：对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。

  3. 项目根目录/src/main/java：放置项目Java源代码

    项目根目录/src/main/resources：放置项目静态资源和配置文件
    项目根目录/src/test/java：放置项目测试用例代码
    |_annotation：放置项目自定义注解
    |_aspect：放置切面代码
    |_config：放置配置类
    |_constant：放置常量、枚举等定义
    |constnt：存放常量定义
    |    enums：存放枚举定义
    |_controller：放置控制器代码
    |_filter：放置一些过滤、拦截相关的代码
    |_mapper：放置数据访问层代码接口
    |_model：放置数据模型代码
    |entity：放置数据库实体对象定义
    |    dto：存放数据传输对象定义
    |vo：存放显示层对象定义
    |_service：放置具体的业务逻辑代码（接口和实现分离）
    |    intf：存放业务逻辑接口定义
    |__impl：存放业务逻辑实际实现
    |_utils：放置工具类和辅助代码

    接口

    主要参考《后台规范JAVA篇》：

  4. 接口的命名通常由多个独立的单词组成，每个组成的单词必须首字母大写，其它所有字母 小写。接口的命名应当简短、突出重点。通常情况下，应当避免使用缩略语来命名类，除非该缩略语已被熟知。

  5. POJO 类中布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。
  6. 杜绝不规范的缩写，避免望文生义
  7. 接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁 性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是 与接口方法相关，并且是整个应用的基础常量。
  8. 控制流语句 if、for、while、switch 和 try 不可以嵌套过深（默认值为 3，超过 3 层必须每层 加逻辑注释）

  9. 接口路径中包含具体接口名称的名词，接口数据操作动作以HTTP请求方式来区分。常用的HTTP请求方式有：

    GET：从服务器取出资源（一项或多项）。
    POST：在服务器新建一个资源。
    PUT：在服务器更新资源（客户端提供改变后的完整资源）。
    PATCH：在服务器更新资源（客户端提供改变的属性）。
    DELETE：从服务器删除资源。

  10. 各层命名规约：

A) Service/DAO 层方法命名规约
1） 获取单个对象的方法用 get 做前缀。
2） 获取多个对象的方法用 list 做前缀，复数形式结尾如：listObjects。
3） 获取统计值的方法用 count 做前缀。
4） 插入的方法用 save/insert 做前缀。
5） 删除的方法用 remove/delete 做前缀。
6） 修改的方法用 update 做前缀。
B) 领域模型命名规约
1） 数据对象：xxxDO，xxx 即为数据表名。
2） 数据传输对象：xxxDTO，xxx 为业务领域相关的名称。
3） 展示对象：xxxVO，xxx 一般为网页名称。
4） POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

  1. 获取信息类接口均使用get类型
  2. 新增接口使用post类型,并返回新增的实体类列表
  3. 修改接口使用post类型,并返回修改后的实体类列表
  4. 删除接口使用delete类型,彻底删除接口以/completelyDelete命名.不然接口默认为假删(删除标记置位那种)
  5. 删除接口默认无返回,以统一封装格式的code为基准判断成功与否即可
  6. 导入接口使用post,并以/import/**命名,数据量较小情况下返回导入后的实体类列表
  7. 导出接口使用get,并以/download/*命名
  8. get和delete接口的参数均跟在url后
  9. post请求参数均放body里
  10. 返回数据字典接口格式,均已/**/dic命名 例如在用户的接口下返回 [{“label”:”姓名”,”id”:1}]这样的格式供前端下拉框使用的场景
  11. 返回实体类某个字段的字典表时,以/字段名/dic命名 如用户实体类的sex字段1为男人,0为女人 命名为/sex/dic
  12. 统计接口均以/chart/**命名,一般情况下独立controller
  13. 接口上复杂的业务逻辑需要说明 对前端提供接口需说明调用接口产生的业务后果 对提供后端的接口需要详细说明入参出参,尤其入参有无限制