Understanding VO, DTO, DO, and PO: Concepts, Differences, and Practical Application

This article discusses the commonly used objects in Java backend development: VO (View Object), DTO (Data Transfer Object), DO (Domain Object), and PO (Persistent Object), describing their concepts and how they fit into a three‑layer architecture.

Concepts

VO (View Object): An object used in the presentation layer to encapsulate all data required by a specific page or component.

DTO (Data Transfer Object): Originating from J2EE design patterns, DTO is used to transfer data between the presentation layer and the service layer, reducing remote calls and network load.

DO (Domain Object): An abstraction of a business entity derived from the real world, representing either tangible or intangible concepts.

PO (Persistent Object): An object that maps one‑to‑one with the data structure of the persistence layer (usually a relational database).

Model

The following sequence diagram illustrates where each object resides in a typical three‑layer application:

VO vs DTO

Although VO and DTO often contain the same attributes, they serve different design purposes: DTO represents the data required by the service layer, while VO represents the data needed for display. Keeping them separate preserves the single‑responsibility principle and prevents coupling of business logic with presentation details.

When the client is single, requirements are stable, or the presentation can perform the necessary transformation (e.g., via JavaScript or CSS), VO can be omitted and DTO used directly.

Conversely, in scenarios with multiple clients, customizable UI, or complex view composition, maintaining both VO and DTO is advisable.

DTO vs DO

DTO is a flat data carrier between presentation and service layers, while DO encapsulates domain logic and may contain attributes not intended for the UI. DOs often have business methods and may be linked to multiple DTOs, making a one‑to‑one mapping unrealistic.

Exposing DOs directly to the UI can lead to unwanted coupling, security issues, and transaction management problems, especially when using ORM frameworks with lazy loading.

DO vs PO

In many cases DO and PO correspond one‑to‑one, but differences arise when persistence strategies differ, when certain domain objects do not need to be persisted, or when PO contains technical fields (e.g., version for optimistic locking) that have no business meaning.

Modern ORM tools (e.g., JPA, Hibernate) often blur the line between DO and PO, yet developers must still be aware of transient fields and proper encapsulation.

Conclusion

Design and implementation are separate concerns: even if technical means allow merging concepts, designers should keep VO, DTO, DO, and PO distinct in their minds to maintain clear architecture and facilitate future evolution.