这篇文章主要为大家展示了“java开发MVC三层架构上再加一层Manager层原理的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“java开发MVC三层架构上再加一层Manager层原理的示例分析”这篇文章吧。
MVC三层架构
我们在刚刚成为程序员的时候，就会被前辈们 “教育” 说系统的设计要遵循 MVC（Model-View-Controller）架构。它将整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
MVC分层架构是架构上最简单的一种分层方式。为了遵循这种分层架构我们在构建项目时往往会建立这样三个目录：controller、service 和 dao，它们分别对应了表现层、逻辑层还有数据访问层。
每层的作用如下：
Controller层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理。
Service层：主要是处理业务逻辑和事务
Dao层：负责与底层数据库MySQL，Oracle等进行数据交互
可是随着我们的业务逻辑越来复杂，代码写的越来越多，这种简单的三层架构的问题也越来越明显。
MVC架构弊端
传统的MVC分层有以下几个很明显的问题：
Service层代码臃肿
Service层很容易出现大事务，事务嵌套，导致问题很多，而且极难排查
dao层参杂业务逻辑
dao层sql语句复杂，关联查询比较多
为了解决这个问题，我们参考《alibaba java开发手册》，在Service层之下再独立出一个通用业务处理层（Manager层）
在这个分层架构中主要增加了 Manager 层，它与 Service 层的关系是：Manager 层提供原子的服务接口，Service 层负责依据业务逻辑来编排原子接口。
Manager层的特征
在《alibaba java开发手册》中是这样描述Manager层的：
Manager 层：通用业务处理层，它有如下特征：
对第三方平台封装的层，预处理返回结果及转化异常信息，适配上层接口；对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；与 DAO 层交互，对多个 DAO 的组合复用。
在实际开发中我们可以这样使用Manager层
复杂业务，service提供数据给Manager层，负责业务编排，然后把事务下沉到Manager层，Manager层不允许相互调用，不会出现事务嵌套。
专注于不带业务sql语言，也可以在manager层进行通用业务的dao层封装。
避免复杂的join查询，数据库压力比java大很多，所以要严格控制好sql，所以可以在manager层进行拆分，比如复杂查询。
当然对于简单的业务，可以不使用Manager层。
Manager层使用案例
这里我们举个例子说明一下Manager层的使用场景：
假设你有一个用户系统，他有一个获取用户信息的接口，它调用逻辑Service层的 getUser 方法，getUser方法又和 User DB 交互获取数据。如下图左边展示部分。
这时，产品提出一个需求，在 APP 中展示用户信息的时候，如果用户不存在，那么要自动给用户创建一个用户。同时，要做一个 HTML5 的页面，HTML5 页面要保留之前的逻辑，也就是不需要创建用户。
此时按照传统的三层架构，逻辑层的边界就变得不清晰，表现层也承担了一部分的业务逻辑，因为我们往往会在表现层Controller中增加业务逻辑处理，将获取用户和创建用户接口编排起来。
而添加Manager层以后，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层，每一层的边界就非常清晰了。
接下来我们看一段实际代码说明一下Service层与Manager层如何进行区分？
