MVC三层架构我们刚成为程序员的时候，被jddsn“教育”了，说系统的设计遵循MVC(model-view-controller )架构。 它将整个系统分为Model、View、Controller三个层次，即用户视图和业务处理分开，并通过控制器连接，较好地实现表达和逻辑的解耦，是标准的软件层次结构。
MVC分层体系结构是体系结构中最简单的分层方案。 为了遵循此层次结构，在生成项目时，通常会创建三个目录：控制器、服务和dao。 它们分别对应于表示层、逻辑层和数据访问层。
各层的作用如下：
Controller层：主要是访问控制的传输、各种基本参数的检查或不复用业务的简单处理。 服务层——主要处理业务逻辑和事务的Dao层——负责与底层数据库MySQL、Oracle等的数据交换，但随着业务逻辑的复杂，代码将会被编写出来，以此类推
MVC体系结构的弊端传统的MVC分层存在以下明显问题：
Service层代码庞大的Service层容易发生大事务，事务嵌套，因此存在很多问题，而且dao层参与业务逻辑的dao层的sql语句非常难排除为了解决此问题，相关查询在服务层下独立了另一个公用业务处理层(管理器层)，见《alibaba java开发手册》
此分层体系结构中主要添加了管理器层，管理器层提供原子服务接口，服务层负责根据业务逻辑组织原子接口。
管理器层的特征在《alibaba java开发手册》中对管理器层进行了如下说明。
经理层：是一种常见的业务处理层，具有以下特点：
对于第三方平台封装的层，通过预处理返回结果、转换异常信息、适当组合层接口的缓存计划、中间件通用处理等与服务层通用能力的下沉DAO层进行交互，将多个DAO的组合在实际开发中，可以这样使用Manager层
复杂的业务、服务向Manager层提供数据，负责业务组织，使事务下沉到Manager层。 Manager层不允许相互调用，不会嵌套事务。 也可以集中于无业务的sql语言，在manager层进行通用业务的dao层封装。 避免复杂的join查询比java对数据库的压力更大，因此必须严格管理sql。 因此，可以在manager层中拆分，如复杂的查询。 当然，在简单的业务中，可以不用管理器层。
使用管理器层的示例此处通过示例说明使用管理器层的场景。
假设您有一个用户系统，其界面用于获取用户信息。 它调用逻辑服务层的getUser方法，getUser方法与User DB进行交互以检索数据。 下图的左侧表示部分。
此时，产品提出一个需求，在APP上展示用户信息时，如果用户不存在，就会自动为用户创建用户。 另外，要创建HTML5页面，HTML5页面必须保留以前的逻辑。 这意味着不需要创建用户。
在这种情况下，传统的三层体系结构不清楚逻辑层的边界，而表示层也是业务逻辑的一部分。 这是因为通常会向表示层Controller添加业务逻辑处理，以捕获用户和创建用户界面。
添加管理器层后，管理器层提供用于创建用户和获取用户信息的接口，服务层负责装配这两个接口。 这将使分布在表示层的业务逻辑统一为服务层，从而使每一层的边界非常清晰。
接下来，我们将查看实际代码，并说明服务层和管理器层是如何区分的。
@ transactional (roll back for=throwable.class ) publicresultstringupordown (long departmentid， Long swapId )//验证1 depardown if (部门实体==null ) { return Result.error )“部门xxx不存在”//验证2 departmentityy if(swapentity==null ) { return Result.error )“部门xxx不存在”//验证3 long count=employee Dao.countbydepartmentid (部署日期) if (计数！=null count0(返回结果. error ) (“员工不存在”)； //操作数据库4长部件
Sort = departmentEntity.getSort(); departmentEntity.setSort(swapEntity.getSort()); departmentDao.updateById(departmentEntity); swapEntity.setSort(departmentSort); departmentDao.updateById(swapEntity); return Result.OK("success");}上面代码在我们在我们采用三层架构时经常会遇到，那么它有什么问题呢？
上面的代码是典型的长事务问题（类似的还有调用第三方接口），前三步都是使用 connection 进行验证操作，但是由于方法上有@Transactional 注解，所以这三个验证都是使用的同一个 connection。
若对于复杂业务、复杂的验证逻辑，会导致整个验证过程始终占用该 connection 连接，占用时间可能会很长，直至方法结束，connection 才会交还给数据库连接池。
对于复杂业务的不可预计的情况，长时间占用同一个 connection 连接不是好的事情，应该尽量缩短占用时间。
说明：对于@Transactional 注解，当 spring 遇到该注解时，会自动从数据库连接池中获取 connection，并开启事务然后绑定到 ThreadLocal 上，如果业务并没有进入到最终的 操作数据库环节，那么就没有必要获取连接并开启事务，应该直接将 connection 返回给数据库连接池，供其他使用。
所以我们在加入Manager层以后可以这样写：
DepartmentService.java public Result<String> upOrDown(Long departmentId, Long swapId) { // 验证 1 DepartmentEntity departmentEntity = departmentDao.selectById(departmentId); if (departmentEntity == null) { return Result.error("部门xxx不存在"); } // 验证 2 DepartmentEntity swapEntity = departmentDao.selectById(swapId); if (swapEntity == null) { return Result.error("部门xxx不存在"); } // 验证 3 Long count = employeeDao.countByDepartmentId(departmentId); if (count != null && count > 0) { return Result.error("员工不存在"); } // 操作数据库 4 departmentManager.upOrDown(departmentSort,swapEntity); return Result.OK("success");} DepartmentManager.java @Transactional(rollbackFor = Throwable.class)public void upOrDown(DepartmentEntity departmentEntity ,DepartmentEntity swapEntity){ Long departmentSort = departmentEntity.getSort(); departmentEntity.setSort(swapEntity.getSort()); departmentDao.updateById(departmentEntity); swapEntity.setSort(departmentSort); departmentDao.updateById(swapEntity);}将数据在 service 层准备好，然后传递给 manager 层，由 manager 层添加 @Transactional事务注解进行数据库操作。
！！！更多精彩内容，请点击下方卡片并关注！！！