Backend Development 18 min read

Understanding VO, DTO, DO, and PO: Concepts, Differences, and Practical Application in a Three‑Tier Architecture

This article explains the definitions of View Object (VO), Data Transfer Object (DTO), Domain Object (DO), and Persistent Object (PO), compares their roles, illustrates their placement in a three‑layer architecture, and provides guidance on when to merge or separate these objects in real‑world backend development.

Code Ape Tech Column

Sep 13, 2022

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): Originating from J2EE design patterns, it is a coarse‑grained data carrier between the presentation layer and the service layer, intended to reduce remote calls and network load.

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

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‑tier architecture.

The 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 constructs (or rebuilds) a DO from the DTO and executes business logic.

The service layer transforms the DO into a PO (using an ORM or manually) and persists it via the persistence layer.

Reverse operations (e.g., reading data) follow a similar conversion flow.

Difference Between VO and DTO

Although VO and DTO often share the same attributes and are both POJOs, they serve different design concerns: a DTO represents the data contract between the presentation and service layers, while a VO represents the data needed for display. Keeping them separate prevents coupling presentation concerns (such as gender display strings) with service‑level semantics.

VO and DTO Usage

In certain scenarios you may merge VO and DTO at the implementation level:

If requirements are stable and there is only a single client, a DTO can replace a VO because the service layer should remain independent of presentation formatting.

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

Conversely, keep VO and DTO separate when:

The opposite of the above situations applies.

A framework automatically maps POJOs to UI fields, making a dedicated VO beneficial.

A “large view” requires data from multiple services, making separate VOs useful for composition.

Difference Between DTO and DO

A DTO is a protocol object exchanged between the presentation and service layers, whereas a DO models business concepts and may contain domain logic. For example, a UserInfo DTO should omit sensitive fields like password, while the corresponding User DO may include them.

DTO and DO Usage

Although a service could return a DO directly, using a DTO provides several advantages:

One DTO may correspond to multiple DOs (or vice versa), reflecting complex domain relationships.

DOs can contain data that should not be exposed to the presentation layer.

Exposing DOs allows the presentation layer to bypass service‑level access control and transaction management.

Lazy‑loading mechanisms (e.g., Hibernate) can cause runtime exceptions if DOs are accessed outside a transaction.

Keeping the presentation layer dependent only on the service layer avoids unnecessary coupling to the domain layer.

DTOs should be flat, two‑dimensional objects. Embedding full object graphs (e.g., nested Address, Account, Region objects) can dramatically increase network payload and degrade performance in distributed systems.

Difference Between DO and PO

In most cases DO and PO map one‑to‑one, but there are notable exceptions:

Some DOs (e.g., discount strategy implementations) exist only in memory and have no persistent representation.

Some PO tables (e.g., a join table for many‑to‑many relationships) have no meaningful domain counterpart.

Performance or persistence strategies may cause a PO to correspond to multiple DOs, or a DO to be split across several PO tables.

POs may contain technical fields (e.g., version for optimistic locking) that have no business meaning in the DO.

DO and PO Usage

Modern ORM frameworks (JPA, Hibernate) often hide PO details inside DOs, reducing the need for separate PO classes.

Non‑persistent DO fields should be marked with @Transient in JPA.

Technical PO fields (e.g., version) must be kept in the DO but hidden from business logic, typically by limiting accessor visibility (protected setters for Hibernate).

Hibernate supports scenarios where a DO maps to multiple PO tables and provides lazy‑loading capabilities.

In summary, VO, DTO, DO, and PO each have distinct conceptual roles. Even if technical solutions allow you to merge them, it is important to keep their design‑level distinctions clear to maintain a clean, maintainable architecture.

WeChat 8.0 has increased the friend limit to ten thousand; feel free to add my main account—first‑come, first‑served.