为什么阿里建议给MVC三层架构多加一层Manager层？

你好，我是蜗牛!

大家应该都知道 MVC（Model-View-Controller）架构。

MVC三层架构

三层架构示意图

MVC架构弊端

传统的MVC分层有以下几个很明显的问题：

为了解决这个问题，我们在Service层之下再独立出一个通用业务处理层（Manager层）

Manager层

在这个分层架构中主要增加了 Manager 层，它与 Service 层的关系是：Manager 层提供原子的服务接口，Service 层负责依据业务逻辑来编排原子接口。

Manager层的特征

在《alibaba java开发手册》中是这样描述Manager层的：

在实际开发中我们可以这样使用Manager层

1. 复杂业务，service提供数据给Manager层，负责业务编排，然后把事务下沉到Manager层，Manager层不允许相互调用，不会出现事务嵌套。

2. 专注于不带业务sql语言，也可以在manager层进行通用业务的dao层封装。

3. 避免复杂的join查询，数据库压力比java大很多，所以要严格控制好sql，所以可以在manager层进行拆分，比如复杂查询。

当然对于简单的业务，可以不使用Manager层。

Manager层使用案例

这里我们举个例子说明一下Manager层的使用场景：

接下来我们看一段实际代码说明一下Service层与Manager层如何进行区分？

上面代码在我们在我们采用三层架构时经常会遇到，那么它有什么问题呢？

上面的代码是典型的长事务问题，前三步都是使用 connection 进行验证操作，但是由于方法上有@Transactional 注解，所以这三个验证都是使用的同一个 connection。

若对于复杂业务、复杂的验证逻辑，会导致整个验证过程始终占用该 connection 连接，占用时间可能会很长，直至方法结束，connection 才会交还给数据库连接池。

对于复杂业务的不可预计的情况，长时间占用同一个 connection 连接不是好的事情，应该尽量缩短占用时间。后台回复关键词 笔记 获取蜗牛哥整理的实战笔记 持续更新

所以我们在加入Manager层以后可以这样写：

将数据在 service 层准备好，然后传递给 manager 层，由 manager 层添加@Transactional事务注解进行数据库操作。

最后说一句(求关注!别白嫖！)

如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、在看。

关注公众号：woniuxgg，在公众号中回复：笔记  就可以获得蜗牛为你精心准备的java实战语雀笔记，回复面试、开发手册、有超赞的粉丝福利！