1。背景一说到应用分层，大部分人都会觉得这不是很简单。共有三层：控制器、服务和映射器。看似简单，但很多人并没有分工负责。在很多代码中，controller做的逻辑比service多，service往往被认为是透传。这其实是很多人在开发代码的时候没有注意到的。反正函数也能用，放哪都无所谓。这往往会导致后面的代码无法复用，层次关系混乱，后续代码的维护非常麻烦。的确，在这些人眼里，层叠只是一种形式。前辈们的代码都是这样写的，其他项目的代码也是这样写的，我就照着做。但是在真正的团队开发中，每个人都有不同的习惯。编写的代码必须有自己的标签。有些人习惯在controller中写很多业务逻辑，有些人习惯在服务之间调用远程服务。结果每个人的开发代码风格就完全不同了。等到后面其他人修改的时候，乍一看，我这个人写的代码和我平时的习惯完全不一样。我在修改的时候，是按照我以前的习惯在改。追随前人，又是一个艰难的选择。一旦选择有偏差，当你的后代维护你的代码时，恐怕他们会骂你。因此，一个好的应用分层需要具备以下几点：便于后续代码的维护和扩展；分层效果需要整个团队接受；各层责任边界清晰。2.如何进行分层2.1。阿里编码规范中阿里规范约束的分层如下：开放接口层：可以直接封装Service方法，暴露为RPC接口；通过Web封装成http接口；执行网关安全控制和流量控制等。终端展示层：各终端的模板渲染展示层。目前主要是velocity渲染、JS渲染、JSP渲染、移动端展示等。Web层：主要是访问控制的转发，各种基础参数的验证，或者对不可复用服务的简单处理等。服务层：相对具体的业务逻辑服务层。管理层：通用的业务处理层，具有以下特点：1、第三方平台封装层，对返回结果进行预处理，异常信息转换；2、Service层通用能力的下沉，比如缓存解决方案、通用中间件Processing；3.与DAO层交互，复用多个DAO。DAO层：数据访问层，与底层MySQL、Oracle、Hbase进行数据交互。阿里巴巴协议中的层比较清晰简单，但是描述的还是太简单了，很多同学对于service层和manager层之间的关系还有些不清楚，导致有许多项目中没有管理层。存在。下面介绍在具体业务中如何实现分层。2.2.优化分层从我们的业务发展中总结出一个比较理想的模型。这里先说明一下，由于我们的rpc框架使用的是thrift，所以可能比其他一些rpc框架比如dubbo多了一层。和controller层类似，顶层controller和TService是我们阿里分层规范中的第一层：轻业务逻辑、参数校验、异常覆盖。通常这种接口很容易改变接口类型，所以业务逻辑一定要轻，甚至不做具体逻辑。Service：业务层，复用性低。建议每个控制器方法必须对应一个服务。不要在controller中安排业务编排。为什么？如果我们在controller层安排业务编排，以后如果要访问thrift，就需要在这里重新安排业务，这样会导致我们每次访问都要复制各个入口层的代码，如图下图：如此大量的重复性工作肯定会导致我们的开发效率下降，所以我们需要将所有的业务编排逻辑都放到服务中：Mannager：可复用逻辑层。这里的Mannager可以是单个服务，比如我们的缓存、mq等，当然也可以是复合的。当需要调用多个Mannager时，这个可以组合成一个Mannager，比如逻辑表连接查询等。如果是httpMannager或者rpcMannager，DAO需要在这一层做一些数据转换：数据库访问层。它主要负责“操作数据库中的某个表，映射到某个java对象”。dao应该只允许自己的服务访问，其他服务必须通过相应的服务才能访问我的数据。3.层次领域模型的改造阿里巴巴编码规范中列出了以下领域模型规范：DO（DataObject）：与数据库表结构一一对应，数据源对象通过DAO层向上传输.DTO（DataTransferObject）：数据传输对象，Service或Manager对外传输的对象。BO（BusinessObject）：业务对象。封装Service层输出的业务逻辑的对象。AO（ApplicationObject）：应用对象。Web层和Service层之间的抽象复用对象模型与表现层很接近，复用度不高。VO（ViewObject）：显示层对象，通常是从Web传输到模板渲染引擎层的对象。Query：数据查询对象，每一层接收来自上层的查询请求。注意2个以上参数的查询封装，禁止使用Map类传输。每一层基本上都有自己对应的领域模型，这就导致有些人过于追求每一层都使用自己的领域模型，从而导致一个对象可能在一个请求中出现3次甚至4次。返回的时候也会有3-4次转换，所以一个完整的request-return有可能会有很多对象的转换。如果真的按照这种方式开发，恐怕不应该再写其他东西了，把这种重复无用的逻辑写一天算了。所以我们不得不采用一个折中的方案：1.让Service/Manager去操作数据域模型。对于这一层，我们原来做的工作是业务逻辑处理和数据组装。2、Controller/TService层的领域模型不允许传递给DAO层，不符合职责划分。3、同样不允许DAO层的数据传给Controller/TService。4.小结总的来说，业务分层对于代码规范更为重要，它决定了以后的代码是否可以复用，职责是否清晰，边界是否清晰。当然，对于这种分层，不同的人有不同的看法，团队中每个人的分层习惯也不同，所以很难权衡一个标准的准则。一般来说，只要职责逻辑清晰，后续维护容易，就是很好的分层。最后，如果你的团队有更好的层次感，或者上面的描述有不对的地方，欢迎大家留言指正。
