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

Concept

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

DTO (Data Transfer Object): An object that carries data between the presentation layer and the service layer, originally introduced in J2EE to reduce remote calls.

DO (Domain Object): An entity that represents a business concept abstracted from the real world.

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

Model

The following sequence diagram (image) shows where each object lives in a three‑tier architecture:

User submits a request (e.g., a form); the data is represented as a VO in the presentation layer.

The presentation layer converts the VO to a DTO required by the service method and sends it to the service layer.

The service layer builds a DO from the DTO, executes business logic, and may convert the DO to a PO for persistence.

The PO is persisted by the data access layer; the reverse flow follows the same conversion steps.

VO vs. DTO

Although VO and DTO often contain identical fields, they serve different conceptual purposes: DTO defines the data contract between presentation and service layers, while VO describes how the data is displayed. Keeping them separate preserves the single‑responsibility principle and prevents coupling of business logic with UI representation.

When to Combine VO and DTO

If requirements are stable, the client is unique, and the presentation does not need a distinct view format, VO can be omitted and a single DTO used.

If the client can perform the necessary transformation (e.g., via JavaScript, JSTL, or CSS), VO may be unnecessary.

When to Keep VO and DTO Separate

When multiple clients or customizable UI styles require different representations of the same data.

When a large view aggregates data from several services, separate VOs help compose the final presentation.

DTO vs. DO

DTO is a flat, two‑dimensional data carrier between layers, while DO models business concepts and may contain behavior. A DTO may correspond to multiple DOs and vice‑versa. DOs often hide data that should not be exposed to the presentation layer and may include business methods that should remain inaccessible to UI code.

DTO and DO Application

DTOs should be flattened to avoid excessive network payloads in distributed systems. For example, instead of returning a nested object graph, include only the necessary attributes (e.g., AccountId, AccountName) directly in the DTO.

DO vs. PO

In most cases DO and PO map one‑to‑one, but differences arise when:

Some DOs are purely in‑memory strategies (e.g., discount strategies) that do not require persistence.

Intermediate tables in many‑to‑many relationships may have PO representations without a corresponding business DO.

Performance or persistence strategies may cause one PO to map to multiple DOs (or the reverse).

DO and PO Application

Modern ORM frameworks (JPA, Hibernate) often blur the line between DO and PO, allowing POJOs to serve as both domain and persistent objects. However, developers must still:

Mark non‑persistent fields with @Transient.

Handle version fields or other persistence‑only attributes carefully to avoid breaking ORM initialization.

Be aware of lazy‑loading pitfalls when exposing DOs to the presentation layer.

Conclusion

Design and implementation layers are independent; even if technology permits merging concepts, designers should keep VO, DTO, DO, and PO distinct in their minds to maintain clear architecture, reduce coupling, and improve maintainability.