引言：
实际开发中，遵守一定的开发规范，不仅可以提高开发效率，还可以提高项目的后续维护性以及项目的扩展性；了解一下本博客的项目设计规范，对项目开发很有意义
一、ORM思想
ORM（Object-Relational-Mapping）在对象模型和关系型模型之间做一个映射（转换）。
目的是为了解决面向对象编程语言的发展和关系型数据库的发展不匹配的问题
可以理解为：
将Java中的数据结构与MySQL数据库中的数据结构做了一一映射，ORM提供了一种通过面向对象的方式来操作数据库的方式。
Java对象和数据库数据对比：
| 模型 | 数据格式 |
| 面向对象的语言（Java） | 类、对象、属性 |
| 关系模型的数据库(MySQL) | 表、行、字段 |
- 一张表对应一个实体类
- 一个字段对应实体类中的一个属性
- 一行数据对应一个根据实体类生成的对象
二 、Entity实体设计
用来和数据库中的表对应，解决的是数据格式在Java和数据库间的转换
可以理解为：
如何设计一个Java实体类，使其可以作为接收数据库中数据的载体
编码规范：Java中将所有数据库的数据，使用Java对象进行表示
- 一张表对应一个实体类
- 类名与表名相关，如 t_user 的实体类名 User
- 一个字段对应一个属性
- 属性名必须由字段决定，字段名由1部分组成，则属性名与字段名保持一致，如 字段名 age的属性名也为 age；字段名由多个部分组成，属性名变成小驼峰命名，如字段名 user_id 的属性名为 userId
- 属性的数据类型必须与字段的类型保持一致（属性仍然是Java的数据类型）
-
对应关系如下：
对应关系 整数 小数 字符 日期 Java byte/short/int/long double String Date MySQL 整数类型（int...） 小数类型（float，double，decimal） char/varchar/enum/text 日期类型（datetime...）
-
- 属性的数据类型必须为引用类型（目的是为了处理数据库中的null值）
- 必须提供封装和无参构造方法，可以根据需要提供有参构造
- 必须实现序列化接口
三、DAO设计模式
DAO模式是一种接口+实现类的模式；
问题分析：
在实际开发中，针对一张表的复杂业务功能通常需要和表交互多次（比如转账）。如果每次针对表的简单操作我们都写一遍，代码中会出现大量的代码冗余
解决思路：
将重复的SQL操作提炼至方法中，达到一条SQL操作多次复用的目的
可以理解：
在实际开发中，可能的情况是我们的项目需求是固定的，但是方法的实现方式不是固定的，这是将所需的SQL方法的声明和技术实现分离，接口负责提供一套规范，实现类负责利用相关技术完成规范，使用时用接口声明引用，优势在于可以提高项目内容的扩展性和后续的维护性。
核心思想
DAO模式目的就是将SQL语句转化为通用SQL语句，并封装成Java方法、提高代码复用性。
DAO设计规范
接口规范：com.xx.dao
- 一张表的SQL操作对应一个接口
- 接口名: 对应表的实体类名+Dao.如UserDao
- 一个SQL对应一个方法(只与sql映射，不映射功能)
实现类书写规范：com.xxx.dao.impl
- 一个实现类实现一个接口
- 实现类名: 接口名+impl,如UserDaolmpl
- 方法实现:使用数据库连接技术实现SQL需求
- 通常不会声明独有方法（使用接口引用，无法使用实现类独有方法）
方法定义规范：:Xxx为对应类名
- 査询多行数据: public List<对象>selectXxxs[By属性名](),如selectUsers()|selectUsersByAge(int age)
- 查询单行数据:public 对象 selectXxxBy属性名().如selectUserByUserld(数据类型 属性名)
- 增: public int insertXxx(存储了添加信息的对象),当字段值较少时,也可以直接传入对应字段的属性声明
- 删: public int deleteXxxBy属性名(筛选条件对应的属性声明),如deleteUserByUserld(int Userld)
- 改: public int updateXxxBy属性名(存储了所有修改相关信息的对象),当涉及字段较少时,也可以直接传入相关属性声明
com.xxx.dao：指的是包名
四、三层架构思想
面向对象设计原则：
各司其职（单一职责）：每个Java对象的职责尽可能单一，每个Java对象只负责做某一件事，目的是为了简单化。
解耦合（开闭原则）：业务的变更，对于Java代码的影响，应该是允许增加代码（开放增加），避免修改代码（关闭修改）。
实际开发时，项目的设计规范，也应该遵守单一职责和解耦合
三层架构
将访问数据库、业务处理、用户交互分为三个模块，遵循单一职责，各司其职，降低耦合
| Java代码层 | 概念 | 作用 | 代码 |
view | 视图层 | 与用户交互， 提醒、收集用户输入数据，展示结果等 | 前端代码 |
service | 业务层 | 封装业务代码，实现业务功能 | 一个用户操作对应一个service方法 |
dao | 数据访问层 | 对数据库进行CRUD操作 | jdbc和sql语句的代码 |
如图示：
五、Service设计模式
执行流程：
视图层->调用业务层->调用DAO
书写顺序：
先写DAO->书写业务层->再写视图层
书写顺序原因：
因为视图层需要业务层的数据支持，而业务层需要DAO的sql支持
Service设计规范
接口：com.xxx.service
实体类：com.xxx.service.impl
- 一个实现类对应一个service接口
- 命名: service接口名+impl
- 方法实现:调用DAOSQL支持+逻辑代码
方法：
- 返回值：
- 查询功能的返回值为List集合或单个对象
- 增删改查及其他功能，通常返回boolean类型
- 参数：需要用户提供的数据都应该为功能的参数，参数模式为单个声明还是对象容器存储由参数的数量决定
- 命名：
- 功能逻辑复杂：以功能命名，如登陆 login，注册 register ，转账 transfer
- 功能逻辑简单（功能结构只与SQL执行结构相关）：在DAO模式命名的基础上更改方法前端的关键字
- 查询：query... ，如查询所有用户信息-queryUsers
- 增加：add...，如新增用户信息-addUser
- 删除：remove...，如根据用户ID删除用户信息-removeUserByUserId
- 更改：change...，如根据用户名修改密码-changeUserByUserName |changePasswordByUserName
视图层
视图层：在实际开发中对应前端页面
规范：
- 包名：com.xxx.view
- 命名：以View结尾
总结
这样子创建一个项目，看上去比较复杂，但是在后续的框架学习中，我们是能够更好理解框架设计的规范，一个好的框架在设计上，也一定时遵循一定的设计规范，例如解耦合和单一职责等特性。
