In software development, it’s surprisingly common to encounter projects where database models (Entities) are used directly as the data models for the user interface. Many justify this approach by saying it’s a straightforward and fast way to move data from one place to another. In the short term, it may indeed seem efficient — but over time, this approach tends to cause more problems than it solves.
The primary purpose of database models is to describe the structure of the database. These models include technical details such as JPA annotations, relationships to other tables, and database-specific constraints. The user interface, on the other hand, needs data in a different form — simplified, user-friendly, and often composed from multiple sources.
When database models are used directly in the UI, a dependency forms between these two layers. Every change in the database structure immediately affects the UI, and vice versa. This makes the system fragile and difficult to maintain. Even a simple column name change can require modifications throughout the entire application.
Database models don’t only contain structural information — they also include data that might not be intended for exposure. When these models are passed directly to the UI, it can unintentionally grant access to information that should never leave the server.
The purpose of a user interface is not to present everything the database knows. Reading the database directly is not much different from opening an Excel sheet without formatting or context. The UI’s purpose is to show users relevant, understandable, and context-aware information. When the database model and the UI are kept separate, it becomes possible to precisely define what data moves where and in what format. This is critical for both security and maintainability.
The solution is to introduce a separate transfer layer that acts as an intermediary between the database and the UI. For this purpose, we use DTOs (Data Transfer Objects), which shape the data into the exact form needed by the user interface. If multiple UIs exist, each can have its own set of DTOs.
A DTO doesn’t care how the data is stored in the database — it only defines how the data is delivered to the UI. This allows the underlying data structure to evolve without breaking the front end, while preserving application integrity and preventing data leaks.
Clear distinctions between data models bring clarity to developers’ work. Each layer of the application has its own role:
the data layer handles persistence,
the service layer manages business logic, and
the UI layer presents data.
Keeping these responsibilities separate ensures the application remains understandable and maintainable for years to come.
In the short term, connecting the database and UI directly might seem like a good idea. It removes an intermediate layer and reduces the amount of code to write. In reality, every omitted layer is like taking a loan of technical debt. DRY and KISS enthusiasts may forever debate the necessity of abstraction layers, but personally, I never want to modify frontend code just because I changed a field in the database from a stored boolean to a dynamically computed value on the server.
This text is written through the lens of JPA, but I’d argue that the same reasoning applies equally well to systems where queries are written in SQL and data is transferred from a REST server to a REST-based UI.