DAO vs Repository Pattern
DAO vs Repository pattern -- persistence-facing vs domain-facing abstractions -- explained with Java examples and interview questions.
Expected Interview Answer
The DAO pattern is a low-level abstraction that wraps raw persistence operations for a single table or entity (CRUD, queries), while the Repository pattern is a higher-level, domain-oriented abstraction that exposes a collection-like interface for aggregate roots and hides the fact that persistence exists at all.
A DAO (Data Access Object) typically mirrors the database schema closely: methods like insertUser(), findUserById(), updateUser() map almost one-to-one to SQL statements or ORM calls, and DAOs are often composed by services that still know they are talking to a database. A Repository sits closer to the domain model: it speaks in terms of aggregates (Order, Customer) and business-meaningful queries (findActiveCustomers()), and the caller treats it like an in-memory collection, unaware of whether the data comes from SQL, a document store, or a cache. In practice a Repository is often implemented using one or more DAOs internally, so the two are complementary layers rather than strict alternatives -- DAO is the persistence-technology-facing layer, Repository is the domain-facing layer.
- Clear separation between persistence details and domain logic
- Repository enables swapping storage technology without touching business code
- DAO keeps schema-specific query logic isolated and testable
- Layering the two together avoids leaking SQL/ORM concerns into services
AI Mentor Explanation
A ground-staff scorer who fills in the raw scorebook ball by ball -- runs, extras, wickets, exact overs -- is like a DAO: they operate directly on the low-level record format and know its structure intimately. A team analyst who instead asks "give me this player’s form over the last five matches" is like a Repository: they think in terms of meaningful cricketing questions, not raw scorebook rows, and don’t care whether that data came from a paper ledger or a digital feed. The analyst’s questions are often answered by combining several scorer entries behind the scenes.
Step-by-Step Explanation
Step 1
Identify the persistence technology
DAOs wrap the concrete data source (SQL table, document collection, external API).
Step 2
Write schema-facing CRUD methods
The DAO exposes operations like insert/find/update/delete tied closely to the storage structure.
Step 3
Define a domain-facing Repository interface
Express operations in business terms (findActiveCustomers(), save(order)) independent of storage.
Step 4
Implement the Repository using one or more DAOs
The Repository composes DAO calls internally, translating between domain objects and persistence records.
What Interviewer Expects
- A clear distinction: DAO is persistence-facing, Repository is domain-facing
- Recognition that a Repository can be implemented using DAOs internally
- Awareness that Repository often works with aggregate roots, not raw tables
- A concrete example distinguishing method naming/intent between the two
Common Mistakes
- Treating DAO and Repository as strictly interchangeable synonyms
- Believing a Repository must never touch SQL directly
- Forgetting that Repository is meant to look like an in-memory collection to callers
- Putting business logic inside a DAO instead of keeping it purely persistence-focused
Best Answer (HR Friendly)
“A DAO is a class that handles the low-level details of talking to a database for one table or entity, using methods that closely mirror the database structure. A Repository is a higher-level abstraction that lets the rest of the application work with domain objects as if they were an in-memory collection, without knowing or caring how they are actually stored. Often a Repository is built on top of one or more DAOs.”
Code Example
interface UserDao {
UserRecord findById(long id);
void insert(UserRecord record);
}
class JdbcUserDao implements UserDao {
public UserRecord findById(long id) {
// raw SQL / JDBC call mapped to a row
return new UserRecord(id, "row-from-db");
}
public void insert(UserRecord record) {
// raw INSERT statement execution
}
}
interface UserRepository {
User getById(long id);
void save(User user);
}
class UserRepositoryImpl implements UserRepository {
private final UserDao dao;
UserRepositoryImpl(UserDao dao) { this.dao = dao; }
public User getById(long id) {
UserRecord record = dao.findById(id);
return User.fromRecord(record); // translate persistence record to domain object
}
public void save(User user) {
dao.insert(user.toRecord());
}
}Follow-up Questions
- Can a Repository work without any DAO underneath it?
- Why might a Repository return domain objects instead of raw database rows?
- How does the Repository pattern support the Dependency Inversion Principle?
- When would you use a DAO directly instead of going through a Repository?
MCQ Practice
1. Which statement best distinguishes DAO from Repository?
DAO wraps raw persistence operations closely tied to schema; Repository presents a domain-oriented, collection-like interface.
2. A Repository implementation commonly...
Repositories are often implemented by composing DAO calls, translating persistence records to domain objects.
3. What does a Repository primarily shield the caller from?
A Repository presents domain objects and collection-like operations, hiding whether data comes from SQL, documents, or elsewhere.
Flash Cards
DAO in one line? — A low-level abstraction wrapping raw CRUD operations tied to a specific storage schema.
Repository in one line? — A domain-facing abstraction exposing a collection-like interface over aggregate roots.
How do they relate? — A Repository is often implemented internally using one or more DAOs.
Key difference in vocabulary? — DAO methods mirror schema (insertUser); Repository methods mirror business intent (findActiveCustomers).