规范

对比传统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 传统写法

 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;@Autowiredprivate 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");}@SneakyThrowsprivate void doBiz(String a ,String b) {if(APP) {// 模拟业务耗时TimeUnit.MILLISECONDS.sleep(1200);}else {}}@SneakyThrowsprivate String doDBCheck2() {// 模拟业务耗时TimeUnit.MILLISECONDS.sleep(500);return "";}@SneakyThrowsprivate 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

SpringBoot - 实践阿里巴巴【Manager 层_通用业务处理层】相关推荐

android ui层交互层业务逻辑层服务层,表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL)...
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦 ...
什么是业务逻辑层（业务层）及业务逻辑层（业务层）的功能
转载地址:http://www.cnblogs.com/whitewolf/archive/2012/05/29/2524881.html 业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务 ...
java实现通用查询_通用业务引用查询服务实现
publicclassBizReferenceServiceimplementsIBizReferenceService {privatestaticMap>ruleMaps;privatest ...
持久层和数据访问层_什么是持久层? JDBC 演变的 Mybatis 架构分析
前言 ORM 持久层指的是:将业务数据存储到磁盘,也具备长期存储能力,只要磁盘不损坏,如果在断电情况下,重启系统仍然可以读取数据 01.JDBC 1.1 什么是 jdbc JDBC(JavaDataB ...
为什么要用impl继承service层_讨论：Service层需要接口吗？
阅读本文大概需要 5 分钟. 前几天刷头条又刷到了「Service层和Dao层真的有必要每个类都加上接口吗?」这个问题,之前简单回答了一波,给出的观点是「看情况」现在结合我参与的项目以及阅读的一些项目 ...
一维卷积层_使用一维卷积层的创新Chatbot
一维卷积层虚拟助手项目 (Virtual Assistant Project) The popularity of chatbots has been on the rise since the p ...
三层架构之业务逻辑层
你好,是我琉忆. 今天我们讲一讲三层架构中的业务逻辑层 1.业务逻辑层的介绍业务逻辑层(Business Logic Layer,简称 BLL)是系统架构中体现核心价值的部分.它的关注点主要集中在业 ...
petshop详解之五：PetShop之业务逻辑层设计
五 PetShop之业务逻辑层设计业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计 ...
petshop4.0 详解之五(PetShop之业务逻辑层设计)[转]
业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域( ...

SpringBoot - 实践阿里巴巴【Manager 层_通用业务处理层】

文章目录

规范

对比传统MVC

小栗子

V1.0 传统写法

V2.0 引入Manager层

源码

SpringBoot - 实践阿里巴巴【Manager 层_通用业务处理层】相关推荐

最新文章

热门文章