对PO、VO、DAO、BO、POJO、DTO等对象的解释

最新推荐文章于 2024-04-03 18:03:46 发布

某科学の超电磁炮

最新推荐文章于 2024-04-03 18:03:46 发布

阅读量148

点赞数

文章标签： java

本文链接：https://blog.csdn.net/aaaaaaachao/article/details/112973116

版权

由Service层输出的封装业务逻辑的对象。
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其他对象。
从业务模型的角度看，见UML元件领域模型中的领域对象。
封装业务逻辑的java对象，通过调用DAO方法，结合PO、VO进行业务操作。
这个对象可以包括一个或多个其他对象。比如一个简历、有教育经历、工作经历、关系等等。我们可以把教育经历对应一个PO，工作经历对应一个PO、关系对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO。这样处理业务逻辑时，我们就可以针对PO去处理。

关于BO的三个概念：
1.只包含业务对象的属性；
2.只包含业务方法；
3.两者都包含。
在实际使用中，认为哪种概念正确并不重要，关键是实际应用中适合自己项目的需要。

持久化对象，跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。
可以看成是与数据库中的表相映射的java对象。
最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。
PO中应该不包括任何对数据库的操作。
好处：可以把一条记录作为一个对象处理，方便转为其他对象。

数据传输对象，Service或Manager向外传输的对象。
这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，减少分布式的调用次数，从而提高分布式调用的性能和降低网络负载。
在此泛指用于指标展示层和服务层之间的数据传输对象。
DTO是一组需要跨进程或网络边界传输的聚合数据的简单容器。
它不应该包含业务逻辑，并将其行为限制为诸如内部一致性检查和基本验证之类的活动。不要因实现这些方法而导致DTO依赖于任何新类。
在设计数据传输对象时，有两种选择：使用一般集合；使用显式getter和setter方法创建自定义对象。
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO
命名规约：数据传输对象：xxxDTO，xxx为业务领域相关的名称。

关注