我要评论java领域模型（pojo / entity / vo/ dto / bo）
一、为什么需要领域模型？
在java开发中，数据在不同场景（如数据库交互、前后端传输、前端展示、业务处理）中承担的角色不同：
- 数据库存储需要与表结构严格对应；
- 前后端传输需要精简敏感信息；
- 前端展示需要格式化数据；
- 业务处理需要组合多源数据。
领域模型的作用：通过“给数据贴标签”，明确数据在不同阶段的职责，避免混乱（如直接用数据库实体返回给前端可能暴露密码等敏感字段）。
二、核心领域模型对比总表
| 模型名称 | 全称 | 核心定位 | 应用场景 | 数据流向 | 是否含业务逻辑 |
|---|---|---|---|---|---|
| pojo | plain old java object | 最基础的java实体，无任何约束 | 所有模型的“基类”概念 | 无特定流向 | 无 |
| entity | 实体类 | 映射数据库表结构的“数据库对象” | 与数据库交互（orm框架） | 数据库↔后端（持久化） | 无 |
| dto | data transfer object | 封装数据传输的“快递盒” | 前后端交互、服务间调用（传参/返回） | 前端→后端、服务→服务 | 无 |
| vo | value （view）object | 封装前端展示数据的“展示板” | 后端返回给前端的展示数据 | 后端→前端（仅输出） | 无 |
| bo | business object | 封装业务逻辑的“业务载体” | 服务层（service）内部业务处理 | 后端内部流转 | 有（业务计算） |
三、分模型详解（附示例）
1. pojo（最基础的“裸数据”）
- 全称：plain old java object（普通老式java对象）
- 核心定位：不依赖任何框架、无特殊约束的基础java类，仅包含属性、get/set方法和构造方法。
- 本质：所有领域模型的“最小单元”——entity、dto、vo等本质上都是pojo的“特殊形态”（增加了场景约束）。
示例代码：
// 纯pojo，无任何注解/继承，仅存数据
public class userpojo {
private long id;
private string name;
private integer age;
// 必须有：无参构造、get/set方法
public userpojo() {}
// get/set省略
}关键特点：
- 不继承任何特定类（如
serializable可选，非必须）； - 不实现任何框架接口（如mybatis的
basemapper）； - 仅用于承载数据，无业务逻辑方法。
2. entity（数据库的“镜像”）
- 全称：实体类（无缩写，强调“与数据库关联”）
- 核心定位：与数据库表一一映射的实体，是“数据库数据在java中的化身”。
- 核心场景：通过mybatis、jpa等orm框架操作数据库（查询、新增、修改）。
示例代码：
// 与数据库user表严格映射
@tablename("user") // mybatis注解：指定对应表名
public class userentity {
@tableid(type = idtype.auto) // 主键+自增策略
private long id; // 对应表中id字段（bigint类型）
@tablefield("username") // 字段名与表一致（若相同可省略）
private string username; // 对应表中username字段（varchar）
private string password; // 对应表中password字段（敏感字段，需加密存储）
@tablefield(value = "create_time", fill = fieldfill.insert)
private localdatetime createtime; // 对应表中create_time字段（datetime）
// 无参构造、get/set方法
}关键特点：
- 字段名、类型与数据库表字段完全一致（含主键、索引、自增等配置）；
- 带有orm框架注解（如
@tablename、@id），明确与数据库的映射关系； - 包含数据库层面的属性（如
createtime、updatetime），但无业务逻辑。
3. dto（数据传输的“快递盒”）
- 全称：data transfer object（数据传输对象）
- 核心定位：专门用于数据传输的载体，解决“传输效率”和“数据安全”问题。
- 核心场景：
- 前端→后端：接收前端提交的参数（如登录、表单提交）；
- 服务间调用：微服务a向微服务b传递数据（仅传必要字段）。
示例1：接收前端登录参数
// 前端登录时传递的参数（仅包含必要字段）
public class logindto {
@notblank(message = "用户名不能为空") // 可加参数校验注解
private string username;
@notblank(message = "密码不能为空")
private string password;
// get/set方法
}示例2：服务间传输用户简信息
// 微服务间传输的用户数据（屏蔽敏感字段）
public class usersimpledto {
private long id;
private string username; // 仅传用户名，不含password
private string role; // 仅传必要的角色信息
// get/set方法
}关键特点：
- 字段按需设计（仅包含传输所需的字段，避免冗余）；
- 可包含参数校验注解（如
@notblank），用于前端传参校验； - 不包含数据库相关字段（如
createtime），与数据库解耦。
4. vo（前端展示的“展示板”）
- 全称：value object（值对象）
- 核心定位：专门为前端展示准备的数据，是“后端给前端的最终数据包装”。
- 核心场景：后端接口返回给前端的数据（如页面列表、详情页展示）。
示例代码：
// 前端用户列表页展示的数据（组合多表字段+格式化）
public class userlistvo {
private long userid; // 前端习惯用userid，而非id
private string username; // 用户名（来自userentity）
private string rolename; // 角色名称（来自roleentity，userentity中无此字段）
private string createtimestr; // 格式化后的时间（如"2024-05-01"，前端直接展示）
// get/set方法
}关键特点：
- 字段名可贴合前端习惯（如
userid而非id）； - 可组合多个entity的字段（如用户信息+角色信息）；
- 包含格式化后的字段（如日期转字符串），减轻前端处理成本；
- 绝对不含敏感字段（如
password绝不会出现在vo中）。
5. bo（业务处理的“计算器”）
- 全称：business object（业务对象）
- 核心定位：服务层（service）内部使用的“业务数据载体”，包含业务逻辑处理结果。
- 核心场景：复杂业务计算（如订单金额计算、用户积分统计）。
示例代码：
// 订单业务处理的bo（包含业务计算逻辑）
public class orderbo {
// 基础数据（来自entity）
private orderentity order; // 订单基本信息
private list<orderitementity> items; // 订单项列表
// 业务计算结果（非数据库字段）
private bigdecimal totalamount; // 总金额（计算：sum(单价×数量)）
private bigdecimal discountamount; // 折扣金额（根据会员等级计算）
private bigdecimal payamount; // 实付金额（totalamount - discountamount）
// 业务方法：计算金额（包含核心业务逻辑）
public void calculateamount(userentity user) {
// 1. 计算总金额
this.totalamount = items.stream()
.map(item -> item.getprice().multiply(new bigdecimal(item.getquantity())))
.reduce(bigdecimal.zero, bigdecimal::add);
// 2. 计算折扣（会员等级越高，折扣越大）
this.discountamount = calculatediscount(user.getviplevel(), totalamount);
// 3. 计算实付金额
this.payamount = totalamount.subtract(discountamount);
}
// 私有辅助方法（业务逻辑细节）
private bigdecimal calculatediscount(integer viplevel, bigdecimal total) {
if (viplevel >= 3) return total.multiply(new bigdecimal("0.1")); // 10%折扣
if (viplevel >= 2) return total.multiply(new bigdecimal("0.05")); // 5%折扣
return bigdecimal.zero;
}
// get/set方法
}关键特点：
- 可组合多个entity或dto的数据（如订单+订单项+用户信息）；
- 包含业务计算结果（非数据库存储的临时字段）；
- 有业务逻辑方法（如
calculateamount），是“业务逻辑的载体”； - 仅在服务层内部使用，不暴露给前端或其他服务。
四、场景串联：一个流程看懂所有模型
以“用户查询订单详情”为例，看各模型如何配合：
- 数据库查询：通过
orderentity和orderitementity从数据库获取原始订单数据； - 业务处理：在service层用
orderbo组合上述entity，计算totalamount、discountamount等业务数据； - 传输准备：若需要调用“用户服务”获取会员信息，用
usersimpledto传输精简的用户数据； - 前端展示：将
orderbo中的核心信息（过滤敏感字段、格式化日期）封装到orderdetailvo，返回给前端展示。
整个过程中，pojo是所有模型的基础（上述模型均符合pojo的基本结构）。
五、核心原则总结
- 各司其职：
- 数据库交互用entity，传输数据用dto，展示用vo，业务处理用bo，避免混用（如禁止用entity直接返回给前端）。
- 按需设计：
- 简单项目可简化（如只用entity+dto），复杂项目必须严格区分（如电商系统的订单模块）。
- 转换工具：
- 用mapstruct、beanutils等工具实现模型间转换（如entity→bo、bo→vo），减少重复代码。
到此这篇关于java领域模型示例详解的文章就介绍到这了,更多相关java领域模型内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论