Guidelines for Developing Standard Java Web Applications: Layering, Responsibilities, and Data Types

Introduction

There are frequent online comments claiming that web development is low‑tech and lacks technical depth, or that it never involves multithreading. The author argues that technology has no hierarchy; the value lies in mastering one’s own domain to the extreme.

Web applications are defined as applications that support the HTTP protocol. Every system interacts with others, and HTTP’s simplicity and ubiquity make it a common input/output protocol. With the rise of micro‑services, many web applications no longer only serve HTML pages but also expose RESTful APIs, JSON data, and other HTTP‑based interfaces.

Consequently, complex web systems inevitably encounter multithreading issues.

This article describes how to develop a规范 (standard) Java web application, covering layering, responsibilities of each layer, interaction between layers, and data flow.

Most developers know how to implement a feature and are familiar with the simple three‑layer model (Controller, Service, DAO) and data model objects such as VO, BO, PO, DTO, Model. However, many are unclear about the exact definitions and responsibilities of each component. The goal of this article is to clarify these concepts.

Layering

A typical web application consists of three layers: Controller, Service, and DAO.

Below is a diagram of the three‑layer model:

Controller Layer

The Controller layer acts as the system's Facade. Its responsibilities include:

Receiving system input

Data validation

Protocol conversion

System output

Defining system interfaces

Receiving System Input

Typical sources include path variables, query parameters, request payloads, and user authentication information extracted from the HTTP request.

Data Validation

Basic validation covers data type, range, and format. For example, a transfer‑amount field must be non‑negative. Business‑level checks such as ensuring the amount does not exceed the account balance or the maximum allowed transfer limit belong in the Service layer, not the Controller.

Protocol Conversion

Protocol conversion has two aspects:

Internal data type conversion

Data content protocol conversion

Data transmission format conversion

Internal Data Type Conversion

This includes converting BO to DTO, BO to VO, etc. The next section explains these models in detail.

Data Content Protocol Conversion

For example, an Open API that returns user information may expose only nickname and avatar to Company A, while Company B (a VIP client) receives additional fields such as phone and email. The Service layer returns a UserBO containing all fields; the Controller creates different UserDTOs based on the requesting company, which is the data content protocol conversion.

Data Transmission Format Conversion

This involves serializing objects into JSON, XML, HTML, etc., for HTTP responses.

System Output

After protocol conversion, the data is assembled into an HTTP response and sent to external applications.

Defining System Interface

The capabilities a system provides are defined by its interface, which includes three parts:

Input values

Interface identifier (URL + HTTP method)

Return values

Service Layer

The Service layer handles business logic. Validation such as transfer‑amount limits should be performed here. Depending on complexity, the Service layer can be split into multiple sub‑layers:

Resource Service layer that maps one‑to‑one with database tables

Aggregated business‑logic layer built on top of resource services

Resource Service Layer

Typically corresponds to a single table and its DAO. In SOA, a highly cohesive resource (e.g., UserService, OrderService) is exposed as a service. Other applications should call these services instead of accessing the database directly.

Aggregated Business‑Logic Layer

This layer contains the core business processing, independent of resource access. For simple applications, the Service layer may be a single layer; for complex scenarios, a separate aggregation layer can improve clarity.

Many organizations advocate interface‑oriented programming, leading to a pattern where each Service has an interface (e.g., UserService) and an implementation (UserServiceImpl). While this separates documentation from implementation, it adds an extra class that may be unnecessary if only one implementation exists.

Consider separating interfaces when:

Multiple implementations are possible

The service acts as a façade for external SOA consumers

Complex systems benefit from clearer component relationships

For most web applications, these conditions do not apply, so interface‑implementation separation is often unnecessary.

DAO Layer

The DAO layer should be simple, responsible only for database interactions, without containing business logic.

Data Types

Common data types include PO, BO, VO, DTO, Model, and POJO.

PO (Persistence Object)

Represents a database table; its fields map one‑to‑one with table columns.

BO (Business Object)

Used within business components; may contain more or fewer fields than a PO. One PO can correspond to multiple BOs.

VO (View Object)

Used solely for rendering data on the front‑end.

DTO (Data Transfer Object)

Used for transferring data between systems; typically implements Serializable.

Model

Represents form data, usually corresponding to request payloads.

POJO (Plain Ordinary Java Object)

A simple Java bean used only to represent data types, independent of business logic.

Combining Data Types with Layers

In theory, each data type should appear only in specific layers:

po → DAO layer, Resource Service layer

bo → Service layer, Controller layer

vo, dto, model → Controller layer

Diagrams illustrate these relationships.

Strict adherence to the model can lead to many classes with almost identical fields and mechanical conversion code. In most simple systems, fields across types are nearly identical, so lower‑level objects can be promoted upward (e.g., a PO used directly in Service and Controller layers) while higher‑level types (VO, DTO, Model) should not appear in Service or DAO layers.

Note that a DTO from another system may correspond to a PO in the current system. Therefore, DTOs flowing within the Service layer effectively act as PO roles, but external DTOs should not appear in the Service layer.

Conclusion

All activities benefit from standards; web development is no exception. Standards bring cleanliness, maintainability, and understandability, and are essential for a programmer’s growth. The presented layering and data‑type concepts reflect personal experience and may differ from other guidelines.

Standards are agreements, not mandates; they should be clear and practicable. Everyone can define their own conventions as long as they are widely understandable.

Note: The names of layers and types are role definitions; actual project naming may vary as long as the team agrees.