java 项目分层 PO、VO、BO、DTO、DAO、POJO个人项目实践中的见解

Java项目分层模型解析

大家做了很多的项目,发现好多的架构分层和实体类的分层。
发现一个问题,一个人的项目 自己做着做着就为了省事 混着用,多人团体项目,可能从一开始就用错了,大家就将错就错。
这样就出现一个问题:分层到底怎么tm的分…当自己建立一个项目的时候,拔剑四顾心茫然,当我在旧的项目里面扒拉屎的时候,脑子混乱。作者现在还没有读DDD领域,但是频繁的遇见这样的问题的时候,说明你已经到时候读读书了(后面看完了,会继续完善该文章的),同时也是和各位看官共勉。

前面算是前沿,按照我个人的经验来看,下面的图和定义,很可能让人陷入到形而上学,实际上类只有一个核心的目的:谁用 || 用于谁 || 作用于谁 || 返回给谁 举个例子:VO给谁用,给前端用,那就是需要返回给前端,那就是在Controlller 层定义返回值(return value)。

public BasePageVO<DeviceListVO> queryDeviceList(xxx)

直接整图:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
图多不多,整昏你,来继续上定义
一种是基于 DDD(领域驱动设计) 的术语体(VO/DTO/BO/PO/DO),另一种是更偏向 工程实践中的 POJO 分类(vo/query/entity/dto)。

分层领域模型规约:
VO:(View Object)视图对象,一般位于Controller层,用于展示视图。
DTO:(Data Transfer Object)数据传输对象, 即RPC 接口请求或传输出去的对象,用于展示层与服务层之间的数据传输对象。
BO:(Business Object)业务层对象,一般位于Service层,它与 DO 会有一定的属性差别。
PO:(Persistent Object)持久化对象,对象属性与数据库字段形成映射关系。
DO:(Domain Object)领域对象,就是从现实世界中抽象出来的有形或无形的业务实体,可以当成BO;(Data Object)数据层对象,对象属性与数据库字段形成映射关系,可以当成PO
Query:数据查询对象,各层接收上层的查询请求。注意超过 2 个参数的查询封装,禁止使用 Map 类来传输。
POJO
• vo (与前端交互的所有对象,包括接参和返回)
• query (查询的筛选条件,前端传参和后端内部传参通用)
• entity (数据库表基础对象)
• dto(后端内部传输用,例如多张表字段合并到一个对象)

在这里插入图片描述
在这里插入图片描述
如果项目规模小、团队约定宽松:用 DTO 当请求参数 没问题,很多项目都这么干。
Controller层 :DTO 作为前端调用后端的接口参数
Service 层 :DTO 处理后转换成 DO 或者BO 作为参数作为Service 层调Dao 层的数据库
Dao 层 :Dao 返回 Entity (PO)
Service 层: 将Entity (PO) 转换成 DO 或者BO
Controller层 :将 DO 或者BO 转换成VO 作为前端的返回

在这里插入图片描述
更规范的流程

前端
  ↓ (HTTP JSON)
Controller
  → 接收:XXXRequest (VO)
  → 调用 Service
      ↓
Service
  → 将 Request 转为 Domain Object (DO/BO)
  → 调用 DAO
      ↓
DAO
  → 使用 Entity (PO) 操作数据库
  → 返回 Entity 或 查询投影对象
      ↑
Service
  → 组装 BO / 聚合多个 Entity
  → 转为 XXXResponse (VO)
      ↑
Controller
  → 返回 VO 给前端
dto/     → 跨服务用(可选)
vo/      → controller 用
entity/  → dao 用
bo/      → service 用(复杂业务时)
query/   → 查询条件

什么是“跨服务”(Service-to-Service)?
指的是 后端微服务之间的调用,例如:

用户服务(User Service) → 调用 → 订单服务(Order Service)
通过 Feign、Dubbo、gRPC、HTTP + JSON 等方式通信

特点:
后端对后端
通常有强契约(接口版本、字段稳定性要求高)
可能涉及内部敏感字段(如 internalStatus, auditLog)
不暴露给前端

什么时候可以“Entity = BO”?
在以下场景中,可以简化,让 Entity 兼任 BO:

CRUD 简单系统(如后台管理、配置表维护)
业务逻辑极轻,没有复杂规则、状态机、聚合需求
快速原型开发,追求效率而非架构严谨性

在这里插入图片描述

// DAO 层
UserEntity entity = userMapper.selectById(id);

// Service 层
UserBO bo = UserBO.from(entity);
bo.validate(); // 业务校验
bo.updateLastLoginTime();

// 转 VO 返回
return UserVO.from(bo);

简单项目:可用 Entity 兼做 BO,但不要直接暴露给 Controller

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

IT_Octopus

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值