Effective Application Layering: Controllers, Services, and DAOs Explained

Background

Many developers think application layering is simple—just controller, service, and mapper—but often blur responsibilities, placing too much logic in controllers or treating services as mere pass‑throughs. This leads to tangled code, poor reuse, and difficult maintenance.

In team environments, personal habits cause inconsistent layering, making future modifications confusing and error‑prone.

A good layering approach should:

Facilitate maintenance and extension.

Be accepted by the whole team.

Define clear boundaries for each layer.

How to Layer

2.1 Alibaba Specification

The Alibaba coding guidelines define the following layers:

Open Interface Layer : Exposes Service methods as RPC or HTTP interfaces, handling gateway security and traffic control.

Terminal Display Layer : Renders templates for various clients (Velocity, JS, JSP, mobile, etc.).

Web Layer : Performs request routing, basic parameter validation, and simple non‑reusable business handling.

Service Layer : Contains concrete business logic.

Manager Layer : Provides generic business processing with features such as third‑party platform encapsulation, common capabilities (caching, middleware handling), and DAO composition.

Encapsulates third‑party platform calls and normalizes exceptions.

Offers shared capabilities like caching or middleware processing.

Interacts with DAO layer and reuses multiple DAOs.

DAO Layer : Handles data access to MySQL, Oracle, HBase, etc.

2.2 Optimized Layering

Based on our experience, we propose an ideal model that accounts for an extra RPC layer (Thrift) similar to a controller.

1. Controller/TService : Light business logic, parameter validation, and exception handling. It should remain thin to allow easy swapping of interface types.

2. Service : Business layer with low reuse; each controller method should map to a distinct service method. Business orchestration belongs here to avoid duplication when adding new entry points (e.g., Thrift).

3. Manager : Reusable logic layer (e.g., cache, MQ). It can be single‑service or composite, handling data transformation for HTTP or RPC managers.

4. DAO : Database access layer, responsible for mapping tables to Java objects. Only its corresponding Service should access it.

Layered Domain Model Conversion

Alibaba’s guidelines list several domain model types:

DO (Data Object) : Directly maps to database tables, transferred via DAO.

DTO (Data Transfer Object) : Used by Service or Manager to transfer data outward.

BO (Business Object) : Encapsulates business logic output from Service.

AO (Application Object) : Reusable object between Web and Service layers, close to presentation.

VO (View Object) : Passed to template engines for rendering.

Query : Encapsulates query parameters; avoid using generic Maps for more than two parameters.

Mapping of layers to domain models:

Controller/TService – VO/DTO

Service/Manager – AO/BO

DAO – DO

Strictly adhering to separate models for each layer can cause multiple conversions per request, leading to unnecessary overhead. A pragmatic approach is to allow Service/Manager to work directly with data objects while preventing DAO objects from leaking into Controller/TService.

Conclusion

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable systems. While exact conventions may vary between teams, the key is to keep each layer’s purpose distinct and the overall architecture easy to extend and maintain.