dao层如何调用对象_你的项目应该如何正确分层？

你好，欢迎收听极客视点。

说起应用分层，大部分人都会认为这不是很简单嘛，就Controller、Service、Mapper三层。但在“简单”背后，很多人并没有将各层级的职责划分清楚。比如在很多代码中，Controller比Service还多，Service被当成透传了，这是开发代码容易被忽略的地方。这样往往造成层级关系混乱，后续代码无法复用、维护困难。

此前，公众号“咖啡拿铁（ID：close_3092860495）”介绍了优化代码分层的方法，供你参考。

如何进行分层

一个好的应用分层需要具备以下几点：

方便后续代码进行维护扩展；
分层的效果需要让整个团队都接受；
各层的职责边界清晰。

阿里巴巴的分层规范

在阿里的编码规范中，对分层的要求如下：

1. 开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。

2. 终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染、JS 渲染、JSP 渲染、移动端展示等。

3. Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

4. Service 层：相对具体的业务逻辑服务层。

5. Manager 层：通用业务处理层，它有如下特征：一是对第三方平台封装的层，预处理返回结果及转化异常信息；二是对Service层通用能力的下沉，如缓存方案、中间件通用处理；三是与DAO层交互，对多个DAO的组合复用。

6 .DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。

阿里巴巴规约中的分层比较清晰，简单明了，但是描述得还是过于简单了，很多人还是分不清楚Service层和Manager层之间的关系，导致很多项目中根本没有Manager层的存在。下面介绍具体业务中应该如何实现分层。

优化分层

首先需要说明的是，如果RPC框架选用Thrift，可能会比其他的RPC框架多出一层，作用和Controller层类似：

最上层的Controller和TService是阿里分层规范中的第一层：轻业务逻辑、参数校验、异常兜底。通常这种接口可以轻易更换接口类型，所以业务逻辑必须要轻，甚至不做具体逻辑。

其次是Service层，这是业务层，复用性较低，这里推荐每一个Controller方法都对应一个Service，不要把业务编排放在Controller中去做，否则以后你要接入Thrift，又需要把业务编排再做一次，这会导致你每接入一个入口层，代码都得重新复制一份。如下图所示：

这样大量的重复工作必定会导致开发效率下降，所以你要把业务编排逻辑都放进Service层中。

然后是Mannager层，这是可复用逻辑层。这里的Mannager可以是单个服务，比如Cache、MQ等等；也可以是复合的，当你需要调用多个Mannager时，可以将它们合为一个Mannager，比如逻辑上的连表查询等。如果是httpMannager或rpcMannager，还需要在这一层做一些数据转换。

再来看DAO层，这是数据库访问层。主要负责“操作数据库的某张表，映射到某个Java对象”，DAO应该只允许自己的Service访问。

最后顺便聊一聊分层领域模型的转换，在阿里巴巴编码规约中，列举了下面几个领域模型规约：

DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
BO（Business Object）：业务对象，由Service层输出的封装业务逻辑的对象。
AO（Application Object）：应用对象，在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

每一个层基本都有自己对应的领域模型，而有些人过于追求每一层都用自己的领域模型，这就导致在一次请求中，出现多次对象转换。

一个折中的方案是：

允许Service/Manager可以操作数据领域模型。
Controller/TService层的领域模型不允许传入DAO层，这样就不符合职责划分了。
同理，不允许DAO层的数据传入到Controller/TService。

总结

业务分层对于代码规范是比较重要的，决定后续代码是否可复用，是否职责清晰、边界清晰。

以上就是今天的内容，如果你的团队有更好的分层方法，欢迎留言分享。