今天跟同事们一起主要就是否需要按照严格的分层架构来规范当前代码讨论了应用的几个架构问题。

之前第一家公司采用的是经典的SpringMVC架构，主要划分为Controller，Service，DAO三层。Controller层控制页面逻辑，数据库操作通过自己编写hql在DAO层实现，事务控制在Service层。这样的架构容易理解和上手，但是无法对DAO层的代码逻辑进行控制，很容易出现以下问题：

  1. 自定义的hql逻辑比较随意，容易出现多表关联查询导致数据库的执行效率很低。
  2. 容易出现Service层方法的相互调用导致事务嵌套，容易出现很多比较难以排查的bug。
  3. Service层和DAO层的代码都很容易变动，导致编写单元测试的成本比较高，而且DAO层一旦出现bug对应用整体的影响很大，曾经有一次线上应用一直崩溃，查找了2天才发现是因为调用了一个很古老的有问题的DAO层方法。

现在我司采用的架构沿袭自阿里，主要分为Controller，AO（Service），Manager，Mapper（DAO）四层，与经典的MVC3层架构相比多了一层Manager层。今天主要讨论了这一层的存在是否有必要。

@bleedfly的观点是，DAO层只负责CRUD的逻辑，Manager层用于处理多表关联，所有业务逻辑止步AO层。

理论听起来是很有道理，但是如果没有严格的规范控制，就很难确保严格执行。 很常见的一种情况是，如果整个Service层只需要一个方法，该方法的逻辑只是从根据一个主键值从一张表中取一条记录，如果严格按照规范，就需要写一个Manager层方法和一个Mapper（DAO）层方法，而且这两层的方法逻辑是一样的，直接将Mapper注入Service可以达到同样的效果。如果不假思索的话，很容易打破上述代码规范。

严格满足规范有什么好处呢？

  1. Mapper（DAO）层代码很固定，不容易出现文章开头出现的DAO层的严重事故。
  2. 事务控制在Manager层，Manager层方法不允许相互调用，不会出现事务嵌套的问题。
  3. 为了避免在数据库执行join操作，Manager层负责采用循环控制分别查询，可以有效缓解数据库压力。（PS.当前线上业务挂掉，最先挂的肯定都是数据库，尽管通过读写方式的形式简单隔离了一下数据库，但是数据库的瓶颈在代码依然中是着重考虑的方面）

实际工作中经常出现效率和规范冲突的情况，但是满足规范才是保证代码质量和规避风险的最佳实践。所以下班之前把今天有争议的代码都重构了，感觉神清气爽。