Unravel โบ Java concepts โบ Design patterns and architecture
DAO and repository pattern
A DAO (data access object) or repository hides how data is stored behind a small interface such as OrderRepository.findById(id).
Learn these first
At a glance
A librarian: you ask for a book by title and get it, without knowing the shelving system, or whether it came from the basement or another branch.
- 1An interface describes what can be done: Optional<Order> findById(long id), List<Order> findByCustomer(String c), void save(Order o)An implementation talks to JDBC, JPA, a file or an in-memory map.
- 2The service layer depends on the interface, so tests can use an in-memory fake and production uses the real database
- 3Spring Data generates the implementation of such an interface for you from the method names
- 4Keep the repository about one aggregate (an Order with its lines), return domain objects rather than raw rows, and keep transaction handling in the service layer
- A DAO is oriented to tables; a repository is oriented to the domain ("a collection of orders")
- Do not leak the persistence technology: returning JPA entities with lazy collections to the web layer causes LazyInitializationException and N+1 queries; map to DTOs at the boundary
- The interface-plus-implementation split is plain polymorphism; with Spring Data, a JDK dynamic proxy implements the interface at start-up and translates each method call into a query
import java.util.*;public class Orders { record Order(long id, String customer) {} interface OrderRepository { Optional<Order> findById(long id); void save(Order o); } static class InMemoryOrderRepository implements OrderRepository { private final Map<Long, Order> store = new HashMap<>(); public Optional<Order> findById(long id) { return Optional.ofNullable(store.get(id)); } public void save(Order o) { store.put(o.id(), o); } }}Read the full explanation (about 1 min)
A DAO (data access object) or repository hides how data is stored behind a small interface such as OrderRepository.findById(id). The business code asks for objects and never sees SQL or the database driver.
A mental model
A librarian: you ask for a book by title and get it, without knowing the shelving system, or whether it came from the basement or another branch.
How it works
An interface describes what can be done: Optional<Order> findById(long id), List<Order> findByCustomer(String c), void save(Order o). An implementation talks to JDBC, JPA, a file or an in-memory map.
The service layer depends on the interface, so tests can use an in-memory fake and production uses the real database.
Spring Data generates the implementation of such an interface for you from the method names.
Keep the repository about one aggregate (an Order with its lines), return domain objects rather than raw rows, and keep transaction handling in the service layer.
Going deeper
A DAO is oriented to tables; a repository is oriented to the domain ("a collection of orders"). In practice the two words are used interchangeably.
Do not leak the persistence technology: returning JPA entities with lazy collections to the web layer causes LazyInitializationException and N+1 queries; map to DTOs at the boundary.
Avoid generic "save anything" repositories with dozens of query methods; name queries after real use cases.
Under the hood
The interface-plus-implementation split is plain polymorphism; with Spring Data, a JDK dynamic proxy implements the interface at start-up and translates each method call into a query.
Common mistakes
- Business logic in the DAO.
- Exposing database exceptions and entities to the web layer.
- One huge repository for everything.
How Unravel recognises it
When you paste code, Unravel looks for these signs of dao and repository pattern. Spotting them yourself is a good habit when you read unfamiliar code:
- Types:
โฆDaoโฆDAOโฆRepository
Part of a learning path
- Design patterns and SOLID ยท previous: Template method pattern ยท next: SOLID principles
Related concepts
Frequently asked questions
What is DAO and repository pattern?
A DAO (data access object) or repository hides how data is stored behind a small interface such as OrderRepository.findById(id). The business code asks for objects and never sees SQL or the database driver.
What are the most common mistakes with DAO and repository pattern?
Business logic in the DAO. Exposing database exceptions and entities to the web layer. One huge repository for everything.
How can I see DAO and repository pattern in real code?
Paste your own Java into Unravel and it will point out where dao and repository pattern appears, explain how it works at the detail level you choose, and draw the flow of the code around it.