规范
对比传统MVC
说几个弊端
为了解决这个问题，《阿里巴巴泰山版java开发手册》推荐在Service层之下独立出一个通用业务处理层（Manager层）
相比较传统的MVC，主要增加了 Manager 层， 它有如下特征：
- 1） 对第三方平台封装的层，预处理返回结果及转化异常信息
- 2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理
- 3） 与 DAO 层交互，对多个 DAO 的组合复用
实际开发中，
- 对于复杂业务，service调用manager层，然后把事务下沉到Manager层，Manager层不允许相互调用，不会出现事务嵌套。
- 专注于不带业务SQL，也可以在manager层进行通用业务的dao层封装。
- 避免复杂的join查询，可以在manager层严格控制好SQL，应对复杂的SQL查询。
简言之， Manager 层提供原子服务接口，Service 层负责依据业务逻辑来调用原子接口。
小栗子
举个例子说明一下Manager层的使用场景
需求：
- APP 登录的用户，如果系统中没有用户，需要自动创建用户，然后再返回相关的用户信息用于展示
- 网页端登陆的用户，如果系统中没有用户，不自动创建用户，需要用户注册。
反手就是一顿突突啊
V1.0 传统写法
package com.artisan.service; import com.artisan.dao.UserDao; import com.artisan.response.ResponseData; import lombok.SneakyThrows; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; import java.util.concurrent.TimeUnit; /** * @author 小工匠 * @version 1.0 * @mark: show me the code , change the world */ @Service public class ServiceWithoutManager { private final boolean APP = true; @Autowired private UserDao userDao; @Transactional(rollbackFor = Throwable.class) public ResponseData<String> buiz(Long idCard, Long name) { // 验证 1 假设 DB操作 校验 String var1 = doDBCheck1(); // 验证 2 假设 DB操作 校验 String var2 = doDBCheck2(); // 业务 APP -- DB校验 --- 自动创建用户 -- 返回用户信息 // 网页 -- DB校验 --- -- 返回用户信息 doBiz(var1,var2); return ResponseData.success("success"); } @SneakyThrows private void doBiz(String a ,String b) { if(APP) { // 模拟业务耗时 TimeUnit.MILLISECONDS.sleep(1200); }else { } } @SneakyThrows private String doDBCheck2() { // 模拟业务耗时 TimeUnit.MILLISECONDS.sleep(500); return ""; } @SneakyThrows private String doDBCheck1() { // 模拟业务耗时 TimeUnit.MILLISECONDS.sleep(1000); return ""; } }
这有啥子问题？ 常规操作啊…
每日一博 - 常见的Spring事务失效&事务不回滚案例集锦
让我们来分析分析
- 典型的长事务问题 ， 由于方法上有@Transactional 注解，所以验证和业务都是使用的同一个 connection
- 对于复杂业务、复杂的验证逻辑，会导致整个验证过程始终占用该 connection 连接，占用时间可能会很长，直至方法结束，connection 才会交还给数据库连接池。
对于复杂业务的不可预计的情况，长时间占用同一个 connection 连接应该尽量避免，应该尽量缩短占用时间。
@Transactional 注解， AOP 实现，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。
当 Spring 遇到该注解时，会自动从数据库连接池中获取 connection，并开启事务然后绑定到 ThreadLocal 上，对于@Transactional注解包裹的整个方法都是使用同一个connection连接。
如果出现了耗时的操作，比如三方接口调用，业务逻辑复杂，大数据处理等就会导致占用这个connection的时间过长，数据库连接一直被占用不释放。一旦类似操作过多，进而导致数据库连接池耗尽。
V2.0 引入Manager层
将数据在 service 层准备好，然后传递给 manager 层，由 manager 层添加@Transactional事务注解进行数据库操作, 尽量减少大事务带来的危害。
源码
https://github.com/yangshangwei/boot2
