weixin_46866349的博客

它们的区别是, 在共用事务的情景下, a 中代码若抛出了异常, b中的所有操作也会一起撤销, 同理, b中代码出现异常也可能影响a的执行.另外, 异常可能导致数据的不一致性, 例如在需要连续完成的动作间产生了异常, 除了需要进行异常处理并产生错误报告外, 还需要事务特性的支持, 它需要维护代码块执行的原子性., 事务传播行为：指的就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。而在后一种情景, 两个事务独立进行, a 中的异常不会影响 b 的进行(只要事务b开启了)

定义一个类, 实现 Filter 接口，并重写其所有方法.

在未登录情况下，我们也可以直接访问部门管理、员工管理等功能。因此需要登录认证功能。一是登录功能, 也就是在登录界面输入账号密码，经过数据库校验(也即检查账号密码是不是存在的)返回查询结果, 那么前台根据查询结果决定是否跳转到后台管理页面.第二个是认证功能, 这也是较为核心的功能, 也即需要检查用户的登录状态, 未登录时如果直接访问后台管理页面的url, 应当重定向回登录页面.

OSS的参数直接放在代码中, 这不符合开发思想, 一个合理的方法是使用 yml 配置, 将配置文件改为 application.yml. 其好处是以数据为中心, 简洁且层次清晰. properties 文件层次不够清晰。在 java 文件中, 对连接四要素单独用变量存放, 并使用 @Value(${})注解, 此时, 需要把这些关于连接配置的属性单独放在一个实体类。** 注解, 给定前缀, 属性名保持一致, 即可自动注入.

然而, 尝试了许久环境变量相关操作无法正常获取 ACCESS KEY. 因此最终还是把访问密钥放在了代码中(这样看起来似乎十分不合规范), 在 api 接口中, 上传图片的请求方式为 post, 参数即为上传的图片, 可使用 MultipartFile 接收. 创建一个 contoller 处理该请求, 它接收上传过来的 file stream, 上传到 oss, 接着返回访问路径. 前台收到响应后就知道了 url, 随后在点击确定新建时该url就被封装到请求参数实体的url中, 因此, 你惊讶的发现,

注意 SQL 书写的一些细节, and 操作符被放在了后一条件的前面(如果放在前一个的后面, 理论上语法也对, 但此时 PageHelper 会出现拼接语法错误). 查询结果按更新时间降序排序.前两节分别完成了搭建系统整体框架和完善部门管理功能的工作, 这一节则完整的实现员工管理中。此时, 考虑条件查询参数, 再将请求参数封装到实体类。如图所示, 可以借助 PageHelper 简化开发。rows: 查询得到的 Employee 列表。接着在 pojo 包下引入。的功能. 同样的, 需要。

这实际上就算是完成了前后端联调的工作, 此后在前端进行的操作就能够传递给后端, 后端据此做出的响应也能返回给前端并以特定方式呈现. 在这个过程中, 前端项目和后端项目本身是完全分离的, 它们仅仅是遵循了同一份api文档, 最后仍能很简单的无差错的融合在一起。update dao 接口在这里其实也可以静态实现, 因为这里传入的 department 的未修改字段并不是 null, 而是查询出的原始值.然而, 很多情况可以省略第一次的查询操作, 那么这时就必须使用动态SQL了.

本小节主要完成项目文件准备, 以及第一个功能实现: 部门信息展示. 并使用PostMan/Apifox测试接口数据是否正常返回, 复习三层架构的实现以及当初引入三层架构的缘起.也即数据访问层, 该层需要定义数据访问的接口和方法, 新建 mapper 包以存放数据访问代码(这里是通过MyBatis框架访问MySQL数据库的数据表得到的)如上所示, 首先定义了 Service 接口, 这个接口用于与Controller的通信, 其次新建了 impl 子包, 它存放该接口的实现.响应数据: Result。