在使用O/RM框架时，通常将某个数据库表映射为某个Java类，将该表的某列映射为该Java类的某个属性。对此Java类，《阿里巴巴Java开发手册》里称之为DO（Data Object），即与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。也有资料称之为PO（Persistent Object）或Entity。但PO很容易让人和POJO（Plain Ordinary Java Object）混淆。
在Web开发中，提交表单时表单里的信息项需要映射为Controller层某个方法参数里的Java类。其逆过程，如查看某某业务对象详情时，也需要将该Java类交给模板引擎（如Velocity等）进行渲染，或者序列化为JSON串交给前端工程（如Vue等）进行渲染。此场景，对应《阿里巴巴Java开发手册》里哪个我有点不确定。
Service层某方法，可能需要3、5个或更多基本类型参数，通常需要把这些参数封装到一个Java类。此场景，对应《阿里巴巴Java开发手册》里哪个我有点不确定。
某个数据库表映射为某个Java类，该类有20、30个或更多属性，但前端页面仅需要查询并展示其中的很少几个属性。偷懒的做法是直接把该Java类返回给模板引擎或前端工程。但最好是新增一个Java类，要遵循“最少暴露原则”。此场景，对应《阿里巴巴Java开发手册》里哪个我有点不确定。
等等场景。
当团队成员不能简单地和分层领域模型规约对上号时，他就会按自己的理解随便选一个。久而久之，就乱了。基于此，我建议简化处理，仅把领域模型分为两类：一类是DO（Data Object），其余都是DTO（Data Transfer Object）。不建议使用BO（Business Object），当你在开发某个业务系统时，很难分清哪些不是业务对象，莫不如找一个更中性的，即DTO。
举例，假设我们在开发一个简历编辑保存页面和一个查询简历详情页面，简历包括：个人基本信息、教育经历和工作经历。可以建3个DO，对应数据库里3张表：
- BaseInfoDO.java
- EducationalExperienceDO.java
- WorkExperienceDO.java
和1个DTO：
- ResumeDTO.java，该类1对1关联BaseInfoDO.java，1对多关联EducationalExperienceDO.java和WorkExperienceDO.java
附《阿里巴巴Java开发手册》
3.【参考】分层领域模型规约：
DO（Data Object） ：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
DTO（Data Transfer Object） ：数据传输对象， Service 或 Manager 向外传输的对象。
BO（Business Object） ：业务对象。 由 Service 层输出的封装业务逻辑的对象。
AO（Application Object）： 应用对象。 在 Web 层与 Service 层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
VO（View Object） ： 显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
Query：数据查询对象，各层接收上层的查询请求。 注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。
资料
- https://stackoverflow.com/questions/1612334/difference-between-dto-vo-pojo-javabeans
- https://blog.csdn.net/weixin_41485592/article/details/81977539
- https://www.jianshu.com/p/b934b0d72602
- https://my.oschina.net/liaodo/blog/2988512
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/17215.html
