背景
应用分层在软件开发中被广泛应用，通常被划分为控制层（Controller）、业务逻辑层（Service）和数据访问层（Mapper）。然而，许多开发者并没有充分理解和正确划分各层的职责，在实际代码中，控制层往往包含了大量的业务逻辑，而业务逻辑层则变得类似于透传的角色。这是许多开发者容易忽视的问题，他们只关注功能是否实现，对于代码的组织结构并不重视，导致后续代码的复用性差，层次关系混乱，给后续代码的维护带来很大的困难。
如何进行分层
-
开放接口层：这一层封装了服务方法，使其可以以不同的方式暴露，例如封装成RPC接口或通过Web暴露为HTTP接口。同时，开放接口层还负责进行网关安全控制和流量控制等功能。
-
终端显示层：这一层负责各种终端的模板渲染和显示执行。它能够处理多种展示方式，如Velocity渲染、JS渲染、JSP渲染以及移动端展示等。
-
Web层：Web层主要处理访问控制的转发、基本参数校验以及一些不需要复用的简单业务处理等。它作为系统的入口，负责将请求转发给下一层进行处理。
-
Service层：Service层是相对具体的业务逻辑服务层，它包含了系统的核心业务逻辑。在这一层，具体的业务逻辑被实现和封装，以提供给其他层调用和复用。
-
Manager层：Manager层是通用业务处理层，具有以下特点：首先，它封装了对第三方平台的操作，预处理返回结果并转化异常信息；其次，它下沉了Service层的通用能力，如缓存方案和中间件通用处理；最后，它与DAO层进行交互，用于组合和复用多个DAO的操作。
-
DAO层：DAO层是数据访问层，负责与底层的MySQL、Oracle、HBase等数据库进行数据交互。在这一层，实现了数据的增删改查操作，为上层提供持久化数据的访问接口。
阿里巴巴规约中的分层比较清晰简单明了，但是描述得还是过于简单了，以及service层和manager层有很多同学还是有点分不清楚之间的关系，就导致了很多项目中根本没有Manager层的存在。下面介绍一下具体业务中应该如何实现分层。
从我们的业务开发中总结了一个较为的理想模型,这里要先说明一下由于我们的rpc框架选用的是thrift可能会比其他的一些rpc框架例如dubbo会多出一层,作用和controller层类似
最上层controller和TService是阿里分层规范里面的第一层：轻业务逻辑，参数校验，异常兜底。通常这种接口可以轻易更换接口类型，所以业务逻辑必须要轻，甚至不做具体逻辑。
Service：业务层，复用性较低，这里推荐每一个controller方法都得对应一个service,不要把业务编排放在controller中去做，为什么呢？如果我们把业务编排放在controller层去做的话，如果以后我们要接入thrift,我们这里又需要把业务编排在做一次，这样会导致我们每接入一个入口层这个代码都得重新复制一份如下图所示:
这样大量的重复工作必定会导致我们开发效率下降，所以我们需要把业务编排逻辑都得放进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：数据查询对象，用于各层接收上层的查询请求。尤其对于超过两个参数的查询，应该封装成一个Query对象来传递，而不应该使用Map类进行传输。
在典型的应用架构中，每个层次往往都有对应的领域模型。然而，有些人可能过于追求每个层次都使用自己的领域模型，这可能导致在一次请求中出现多次对象转换的情况，增加了代码的复杂性和冗余性。
实际上，在开发过程中，过多的对象转换确实会造成不必要的工作量和代码冗余。如果严格按照每个层次使用独立的领域模型，并进行多次对象转换，那么可能会花费大量的时间和精力在无用的逻辑上，导致开发效率低下。
所以我们得采取一个折中的方案:
总结
原文始发于微信公众号（二进制跳动）：聊聊项目代码的应用分层
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167412.html
