SSM框架的实际使用流程

一、以用户登录功能为例，可以分为四步：

1. 用户-登录-持久层

(a) 分析需要执行的SQL语句

(b) 接口与抽象方法

© 配置映射

2. 用户-登录-业务层

(a) 创建异常

(b) 接口与抽象方法

© 实现业务

3. 用户-登录-控制器层

(a) 处理异常

(b) 设计需要处理的请求

• 请求路径：/users/login
• 请求参数：String username, String password
• 请求类型：POST
• 响应结果：JsonResult<User>

© 处理请求

4. 用户-登录-前端页面

二、细节：

• 在创建数据表时，能够使用数字作为标记的字段，应该使用数值类型，例如“性别”；
• 在创建数据表时，如果字符串的长度固定，应该使用char，如果长度不固定，应该使用varchar；在使用varchar时，应该指定比上限值略大的限制值，例如“用户名”的长度上限为16，则应该设置为varchar(20)或略大于16的其它值；
• 在创建数据表时，应该明确通过charset=xx指定字符编码，且推荐使用utf8mb4；
• 
• 在创建实体类时，每个属性都应该是私有的，应该为每个属性添加Getters & Setters，应该基于id这种唯一标识对应的属性生成hashCode()和equals()（无视方法内容），应该生成完整的toString()以便于观察各属性的值，应该实现Serializable接口并生成其ID；
• 
• 在开发每个功能的各层时，每完成一层，就应该及时测试，持久层和业务层可以通过单元测试来完成测试，控制器层可以通过在浏览器直接输入URL及测试参数来完成测试，一定要保持“做一层，测一层，测试通过再做下一层”的原则；
• 无论是开发哪一层，都应该保持“先分析，再开发，再测试”的原则；
  
• 持久层的主要职责是完成数据的增删改查，并不关心数据从哪里来，也不关心是否应该执行增删改查中的某些操作，这些问题都应该是业务层关心的，所以，持久层的每个功能都非常单一，只关心数据访问的实现；
• 业务层的主要职责是组织业务流程（执行先后顺序），实现业务逻辑（判断是否应该），以保障数据的安全性（数据按照我们设定的规则而产生或发生变化）和完整性（凡不应该由用户提交的数据，都在服务器端的业务层中补全）。
• 业务方法的返回值都是基于“以操作成功为前提条件”来设计的，如果在业务的实现过程中，判定为“失败”，则应该抛出相应的异常对象，并且，在抛出时，通过异常的构造方法封装“失败”的描述信息；
• 应该为每一种错误都创建对应的异常类，且需要有1个自定义异常的基类，其它自定义异常都应该直接或间接的继承自这个基类，而基类异常需要继承自RuntimeException；
• 应该使用统一处理异常的机制对各种可能出现的异常进行处理；
• 无论是业务层，还是控制器层，在对数据的处理流程不够清楚的情况下，或在数据不符合预期的情况下，应该在关键时间点打桩输出相关数据；
• 当完成了前端页面的开发，且点击按钮或进行某些操作时，如果没有预期的结果，甚至页面完全没有反应，应该打开浏览器的Console面板和Network面板，然后，再次执行不符合预期的操作，并观察这2个面板中是否存在可参考的信息。