1. 首页 > 头条

你会吗 你的项目应该如何正确分层

谈到应用程序的分层架构,很多人首先想到的是一个标准的模型,包括控制器(Controller)、服务层(Service)和数据访问层(Mapper)三个主要部分。这听起来似乎很直观和简单,但实际上,很多开发者在实施时并没有明确区分这些层次的具体职责。例如,一些项目中,控制器层的代码量反而超过了服务层,而服务层仅仅作为一个传输介质,这反映了开发过程中容易被忽视的问题。这种模糊的层级职责划分,最终可能导致架构的混乱,使得代码难以复用和维护

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

方便后续代码进行维护扩展;

分层的效果需要让整个团队都接受;

阿里巴巴的编码规范细化了应用程序架构的多个层次,旨在更清楚地界定各层的职责和作用。这些层次包括:

开放接口层:这一层负责将服务层的功能通过RPC接口或HTTP接口向外暴露,同时负责网关的安全和流量控制。

终端显示层:负责在各种客户端上渲染和显示信息,使用不同的技术如Velocity、JavaScript、JSP进行页面渲染和移动端展示。

Web层:处理访问控制和转发,进行基本的参数校验和一些不需要复用的简单业务处理。

服务层(Service层):执行更具体的业务逻辑处理。

管理层(Manager层):作为一个通用业务处理层,具备三个主要功能:封装对第三方平台的调用、下沉Service层的通用能力(如缓存和中间件处理)、以及与数据访问层(DAO层)的交互,实现对数据访问对象的复合使用。

数据访问层(DAO层):直接与数据库(如MySQL、Oracle、Hbase)进行交互的层级。

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

阿里巴巴的架构分层规范中,最顶层由 Controller 和 TService 构成,主要职责是处理轻量级的业务逻辑、进行参数验证和异常管理。

这一层设计的目的是保持足够的灵活性,以便在需要时可以方便地更改或替换接口类型,因此这里的业务逻辑应尽可能简化,有时甚至可以避免实现具体逻辑。

紧接着的是 Service 层,承担着具体的业务逻辑处理。在这个层级,建议采取一种方法:让每一个 Controller 操作都对应一个 Service 方法。

这样做的好处是避免将业务逻辑的编排混入 Controller 层,从而在将来需要接入其他接口类型,如 Thrift 时,可以避免重复编排业务逻辑,减少代码的重复和维护成本。这种方法强调了在不同层之间保持清晰的职责分离,以提高代码的可维护性和可扩展性。

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

接下来是 Manager 层,这一层充当了可复用逻辑的核心角色。在这个层面上,Manager 可以是负责单一功能的服务,如缓存(Cache)、消息队列(MQ)等;同时,它也能够处理更复杂的任务,比如当需要同时调用多个 Manager 服务时,可以将它们组合成一个综合性的 Manager,以处理更为复杂的业务逻辑,如在逻辑上进行类似于数据库连表查询的操作。

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

在阿里巴巴的编码规范中,分层领域模型的转换是一个关键的设计考虑,以确保数据在不同层之间传递时的清晰性和准确性。以下是一些核心领域模型及其用途的概述:

DO(Data Object):数据对象,直接与数据库表结构对应,通过 DAO(数据访问对象)层传输数据源对象。这确保了数据层与数据库的直接映射,便于操作数据库。

DTO(Data Transfer Object):数据传输对象,用于服务层或管理层向外部传输的对象。DTO 主要用于跨层通讯,封装了需要传输的数据,有助于减少一个方法调用所需要传递的参数数量,简化远程接口调用。

BO(Business Object):业务对象,由服务层输出,封装了业务逻辑的对象。BO 体现了业务模型的概念,通常用于封装具体的业务逻辑和业务状态,反映了业务操作的结果。

AO(Application Object):应用对象,位于 Web 层与服务层之间,是一个抽象的复用对象模型,非常贴近于展示层但复用度不高。AO 主要用于处理特定于应用的逻辑和状态,作为不同服务层之间数据传输的中间层。

VO(View Object):视图对象,通常由 Web 层传输至模板渲染引擎层的对象。VO 主要用于展示层数据的封装,专门为用户界面定制,包含了用户界面展示所需的数据。

Query:数据查询对象,用于在各层之间传递查询请求。它允许将查询条件封装为一个对象,使得方法调用更加清晰,同时避免了使用诸如 Map 这类无结构的数据类型来传递多个查询条件,提高了代码的可读性和可维护性。

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

允许 Service/Manager 可以操作数据领域模型。

Controller/TService 层的领域模型不允许传入 DAO 层,这样就不符合职责划分了。

同理,不允许 DAO 层的数据传入到 Controller/TService。

本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://jmbhsh.com/toutiao/34065.html

联系我们

QQ号:***

微信号:***

工作日:9:30-18:30,节假日休息