Spring Boot REST应用中Dto的必要性及使用/弃用影响探讨

Great question—let’s break this down clearly, since disabling Open Session in View (OIV) changes key behaviors around entity handling, but doesn’t eliminate the core reasons for using DTOs.

Short Answer: Yes, you absolutely should keep using DTOs #

Disabling OIV fixes issues like long-lived Hibernate sessions and lazy loading surprises in the view layer, but it doesn’t address the architectural and practical problems that DTOs solve. Let’s dive into the details.

Why DTOs Are Still Critical (Even With OIV Disabled) #

• Separate API Contracts from Database Schema
  Your JPA entities are tightly tied to your database tables—their structure changes when you alter tables, add columns, or adjust relationships. DTOs, on the other hand, define your API’s external contract. This means you can modify your database schema without breaking frontend clients, and you can shape API responses exactly how consumers need them (e.g., combining data from multiple entities, renaming fields) without polluting your entity classes with API-specific logic.

• Avoid LazyInitializationExceptions (Directly Tied to OIV=false)
  When OIV is disabled, the Hibernate session closes as soon as your service layer method finishes executing. If you return an entity directly from your controller, Jackson will try to serialize it—including any lazy-loaded associations (like user.orders). Since the session is already closed, this triggers a LazyInitializationException. With DTOs, you map entities to DTOs inside the service layer (while the session is still open), so you can explicitly load any required associations and avoid this error entirely.

• Control Data Exposure
  Entities often contain sensitive or internal fields (e.g., passwordHash, internalStatus) that you don’t want to expose to external clients. DTOs let you cherry-pick exactly which fields to include in API responses, without cluttering your entities with @JsonIgnore annotations that mix persistence and API concerns.

• Optimize Performance
  DTOs let you fetch only the data your API needs. For example, you can use JPQL constructor queries or Spring Data Projections to retrieve just the fields required for the DTO, reducing database load and network transfer size. Returning full entities can lead to loading unnecessary data (or even entire related entity graphs) that clients don’t use.

What Happens If You Abandon DTOs (With OIV=false) #

• Constant LazyInitializationExceptions
  This is the most immediate pain point. Any lazy-loaded association on your entity will throw an error when Jackson tries to serialize it after the session closes. You might be tempted to switch all associations to FetchType.EAGER, but this leads to N+1 query problems and loads far more data than necessary, crippling performance.

• Tight Coupling Between Database and API
  Every change to your database schema will directly impact your API responses. Rename a column? Your API’s response field name changes, forcing frontend clients to update. Add an internal field? It gets exposed to clients unless you remember to add an @JsonIgnore annotation. This makes your API fragile and hard to maintain.

• Accidental Sensitive Data Leaks
  It’s easy to forget to mark a sensitive field with @JsonIgnore, leading to accidental exposure of data like user passwords or internal system states. DTOs eliminate this risk by only including fields you explicitly define.

• Bloated Controllers
  If you need to combine data from multiple entities for an API response, you’ll end up doing that work in the controller (since you can’t map it in the service without a DTO). This violates the single responsibility principle—controllers should handle HTTP concerns, not data transformation.

Edge Cases Where You Might Skip DTOs (Proceed With Caution) #

There are rare scenarios where skipping DTOs could be acceptable:

• Trivial, simple entities: For example, a Category entity with only id and name fields, no associations, and no sensitive data. Even here, though, using a DTO keeps your codebase consistent.
• Internal-only APIs: If the API is only used by your own services and your team has strict knowledge of entity structures, you might skip DTOs. But you still need to ensure all required associations are loaded in the service layer to avoid lazy loading errors.

内容的提问来源于stack exchange，提问作者Alejandro Agapito Bautista