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

00d02c54a632aae134aa43386bef957e.png

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

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

此前,公众号“咖啡拿铁(ID:close_3092860495)”介绍了优化代码分层的方法,供你参考。

如何进行分层

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

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

阿里巴巴的分层规范

da3d5f59933cdf8c8191aadc53c1c1f1.png 在阿里的编码规范中,对分层的要求如下:

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层类似:

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

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

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

2f7a58565f57279eb6b1189c1b19998f.png
然后是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类来传输。

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

一个折中的方案是:

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

总结

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

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

897d0c143961ede0cbf93570b8ac0d06.png
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值