MVC三层架构
我们在刚刚成为程序员的时候，就会被前辈们 “教育” 说系统的设计要遵循 MVC（Model-View-Controller）架构。它将整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
每层的作用如下：
- Controller层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理。
- Service层：主要是处理业务逻辑和事务
- Dao层：负责与底层数据库MySQL，Oracle等进行数据交互
可是随着我们的业务逻辑越来复杂，代码写的越来越多，这种简单的三层架构的问题也越来越明显。
MVC架构弊端
传统的MVC分层有以下几个很明显的问题：
- Service层代码臃肿
- Service层很容易出现大事务，事务嵌套，导致问题很多，而且极难排查
- dao层参杂业务逻辑
- dao层sql语句复杂，关联查询比较多
为了解决这个问题，我们参考《alibaba java开发手册》，在Service层之下再独立出一个通用业务处理层（Manager层）
此时按照传统的三层架构，逻辑层的边界就变得不清晰，表现层也承担了一部分的业务逻辑，因为我们往往会在表现层Controller中增加业务逻辑处理，将获取用户和创建用户接口编排起来。
而添加Manager层以后，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层，每一层的边界就非常清晰了。
接下来我们看一段实际代码说明一下Service层与Manager层如何进行区分/p>
上面代码在我们在我们采用三层架构时经常会遇到，那么它有什么问题呢/p>
上面的代码是典型的长事务问题（类似的还有调用第三方接口），前三步都是使用 connection 进行验证操作，但是由于方法上有@Transactional 注解，所以这三个验证都是使用的同一个 connection。
若对于复杂业务、复杂的验证逻辑，会导致整个验证过程始终占用该 connection 连接，占用时间可能会很长，直至方法结束，connection 才会交还给数据库连接池。
对于复杂业务的不可预计的情况，长时间占用同一个 connection 连接不是好的事情，应该尽量缩短占用时间。
说明：对于@Transactional 注解，当 spring 遇到该注解时，会自动从数据库连接池中获取 connection，并开启事务然后绑定到 ThreadLocal 上，如果业务并没有进入到最终的 操作数据库环节，那么就没有必要获取连接并开启事务，应该直接将 connection 返回给数据库连接池，供其他使用。
所以我们在加入Manager层以后可以这样写：
将数据在 service 层准备好，然后传递给 manager 层，由 manager 层添加 事务注解进行数据库操作。
！！！更多精彩内容，请点击下方卡片并关注！！！
来源：飘渺Jam
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！