文章目录
- 规范
- 对比传统MVC
- 小栗子
-
- V1.0 传统写法
- V2.0 引入Manager层
- 源码
规范
对比传统MVC
说几个弊端
- Service层代码臃肿
- Service层易出现大事务，事务嵌套，易出问题且难排查
- dao层混杂业务逻辑
- dao层sql语句复杂
- …
为了解决这个问题，《阿里巴巴泰山版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 传统写法
代码语言：javascript复制 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
