阿里巴巴内部关于POJO定义及实际项目应用

本文详细阐述了POJO、DO、DTO、BO、VO等常见对象的概念及其应用场景,并对比了Entity、DataObject与DataTransferObject的区别,为软件开发中的对象设计提供了指导。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

阿里Java开发规范中的定义

1. POJO( Plain Ordinary Java Object) :  专指只有 setter/getter/toString 的简单类,包括 DO/DTO/BO/VO 等。
2. DO( Data Object): 指数据库表一一对应的 POJO 类。 此对象与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。
3. DTO( Data Transfer Object):数据传输对象, Service 或 Manager 向外传输的对象。
4. BO( Business Object):业务对象,可以由 Service 层输出的封装业务逻辑的对象。
5. Query:数据查询对象,各层接收上层的查询请求。注意超过 2 个参数的查询封装,禁止使用Map 类来传输。
6. VO( View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象。
 

下面引用一篇DDD文章里的解释

Entity、Data Object (DO)和Data Transfer Object (DTO):

  • Data Object (DO、数据对象):实际上是我们在日常工作中最常见的数据模型。但是在DDD的规范里,DO应该仅仅作为数据库物理表格的映射,不能参与到业务逻辑中。为了简单明了,DO的字段类型和名称应该和数据库物理表格的字段类型和名称一一对应,这样我们不需要去跑到数据库上去查一个字段的类型和名称。(当然,实际上也没必要一摸一样,只要你在Mapper那一层做到字段映射)

  • Entity(实体对象):实体对象是我们正常业务应该用的业务模型,它的字段和方法应该和业务语言保持一致,和持久化方式无关。也就是说,Entity和DO很可能有着完全不一样的字段命名和字段类型,甚至嵌套关系。Entity的生命周期应该仅存在于内存中,不需要可序列化和可持久化。

  • DTO(传输对象):主要作为Application层的入参和出参,比如CQRS里的Command、Query、Event,以及Request、Response等都属于DTO的范畴。DTO的价值在于适配不同的业务场景的入参和出参,避免让业务对象变成一个万能大对象。

实际项目中的应用

这些只有setter/getter/toString/equals的简单类可以统称为pojo,博主的项目中惯用model即模型一词概况,其中又分query、form、param、entity、dto、bo、vo

query:表示数据查询对象,一般用在分页、列表查询的入参

form:表单对象,一般用在插入、修改的入参

param: 参数,方法入参也可以统称为param,包括分页、列表、插入、修改都可统称为入参

entity:实体对象,一般标识数据库实体类对象,字段和数据库一一对应

vo:显示层对象,controller响应对象

dto:数据对象,一般用于service之间对象传输

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值