当我们刚成为程序员时，我们将受到“教育”，即系统的设计必须遵循MVC（模型视图控制器）架构。它将整体系统分为三个级别：模型（模型），视图（视图）和控制器，即用户视图和业务处理的隔离以及通过控制器连接逻辑的脱钩是标准软件分层体系结构。
MVC分层体系结构是体系结构中最简单的分层方法。在构建项目时，我们经常设置三个目录：控制器，服务和DAO，与性能层，逻辑层和相对应数据访问层。
每一层的作用如下：
但是，随着我们的业务逻辑变得越来越复杂，编写了越来越多的代码，这种简单的三层体系结构的问题越来越明显。
传统的MVC层有以下明显的问题：
为了解决此问题，我们指的是“阿里巴巴Java开发手册”，并独立生产服务层下的一般可使用业务处理层（管理层）
在此分层体系结构中，主要添加了管理器层。它与服务层的关系是：管理层提供原子服务接口，并且该服务层负责根据业务逻辑安排原子接口。
在“阿里巴巴爪哇开发手册”中，它描述了经理层：
经理层：一般业务处理层，它具有以下特征：
在实际开发中，我们可以使用像这样的管理器层
当然，对于简单的业务，您无法使用经理层。
在这里，我们举例说明管理器层的使用场景：
假设您有一个用户系统。他有一个接口来获取用户信息。它调用逻辑服务层的方法，以及获取数据的方法和交互。如下图所示。
目前，该产品提出了需求。当用户信息显示在应用程序中时，如果不存在用户，则有必要自动为用户创建用户。在同一时间，要制作HTML5页，HTML5页面以保留上一个逻辑，是，无需创建用户。
目前，根据传统的三层体系结构，逻辑层的边界尚不清楚，并且性能层还假定了业务逻辑的一部分，因为我们经常在表达式层控制器中添加业务逻辑处理。它将获取用户并创建用户互动。
添加管理层之后，管理器层提供了一个接口来创建用户并获取用户信息，并且该服务层负责组装这两个接口。这样，最初散布在表达式层上的业务逻辑统一到服务层和每一层的边界非常清晰。
接下来，让我们看看如何将ACTVICE层与管理层层区分开？
当我们采用三层式体系结构时，通常会遇到上述代码，那么它有什么问题？
上面的代码是一个典型的长交易问题（类似于调用第三党接口）。前三个步骤用于验证操作，但是由于该方法具有 @transactional注释，因此在同一用途中使用了这三个验证。
如果复杂的业务和复杂的验证逻辑将导致整个验证过程占据连接连接，则职业时间可能很长，直到方法结束为止，连接将返回到数据库连接池。
对于复杂业务的不可预测情况，长期占用相同的连接连接并不好，应尽可能缩短。
注意：对于@transaction，当弹簧遇到注释时，它将自动从数据库连接池中获取连接，然后打开事务，然后将其绑定到螺纹插座。如果业务未输入最终数据库链接，则没有Noto获得连接并开始交易，应将连接直接返回到数据库连接池以供其他使用。
因此，我们可以在加入管理器层之后这样写：
在服务层上准备数据，然后将其传递到管理层层，然后将事务注释添加到管理层以进行数据库操作。