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

Concepts

VO (View 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, it serves as a coarse‑grained data carrier between the presentation layer and the service layer, reducing remote calls and network load.

DO (Domain Object): Represents tangible or intangible business entities abstracted from the real world.

PO (Persistent Object): Maps one‑to‑one with the relational database schema, each table field corresponding to a PO attribute.

Model

Below is a simple sequence diagram illustrating where each object resides in a three‑tier architecture.

User submits a request; form data is represented as a VO in the presentation layer.

The VO is converted to a DTO required by the service method and sent to the service layer.

The service layer constructs a DO from the DTO and executes business logic.

The DO is transformed into a PO (optionally via an ORM) and persisted.

Reverse operations follow a similar conversion flow.

VO vs. DTO

Although VO and DTO often share the same attributes, they serve different design purposes: DTO represents data needed by the service layer, while VO represents data needed for display. Keeping them separate preserves the single‑responsibility principle and prevents presentation concerns from leaking into the service layer.

When requirements are stable and only one client exists, VO can be omitted and a single DTO used. If multiple clients or customizable presentations are needed, maintaining both VO and DTO is advisable.

DTO vs. DO

DTO is a contract between presentation and service layers, whereas DO models real‑world business entities and may contain domain logic. A DTO should be a flat, two‑dimensional object to avoid excessive data transfer in distributed systems.

DO vs. PO

DO and PO are usually one‑to‑one, but differences arise when persistence strategies or performance considerations cause multiple PO per DO or vice versa. PO may contain technical fields (e.g., version for optimistic locking) that have no business meaning in the DO.

Modern ORM frameworks (e.g., JPA, Hibernate) often blur the line between DO and PO, but developers must still handle transient fields and persistence‑only attributes correctly.

Key principle: Design‑level concepts and implementation‑level decisions are independent; even if technology allows merging concepts, the analytical design should keep them distinct for clarity and maintainability.

END