Active Record vs Repository Pattern
Active Record vs Repository pattern — coupling, testability, and when to choose each — explained with a Java example and interview Q&A.
Expected Interview Answer
Active Record bundles data and persistence logic (save, find, delete) directly onto the domain object itself, while the Repository pattern separates persistence entirely into a dedicated interface, keeping domain objects free of any database awareness.
With Active Record, a User object calls user.save() directly, so the object knows about the database; this keeps simple CRUD applications concise but couples domain logic to schema and persistence technology. With Repository, a UserRepository object exposes save(user) and findById(id), and the User object itself has no idea it is being persisted — the domain model stays pure. Repository is generally preferred for applications with rich business logic, complex testing needs, or where persistence technology might change, because it isolates persistence concerns behind an interface. Active Record is preferred for simple, table-per-object CRUD applications where the productivity gain of fewer moving parts outweighs the coupling cost.
- Clarifies when to reach for Active Record vs Repository
- Highlights coupling vs decoupling tradeoffs between the two
- Explains testability differences (fakeable repository vs schema-tied object)
- Connects the choice to application complexity and team scale
AI Mentor Explanation
Active Record is like a player who personally walks to the scorer’s table and updates their own stats after every innings — convenient for one player, but everyone now depends on that same routine being embedded in each player. Repository is like every player instead handing their stats to a dedicated statistician who owns updating and retrieving all records, so players never touch the recording system directly. The tradeoff is the same in code: self-persisting objects are simple but coupled, while a dedicated layer is more work upfront but keeps players (domain objects) clean of recording logic.
Step-by-Step Explanation
Step 1
Assess application complexity
Simple CRUD favors Active Record; rich business logic favors Repository.
Step 2
Check coupling tolerance
Active Record couples domain objects to schema; Repository isolates that coupling behind an interface.
Step 3
Weigh testing needs
Repository is easier to fake/mock in unit tests since domain objects stay persistence-agnostic.
Step 4
Consider future flexibility
If the data store might change, Repository absorbs that change without touching domain logic.
What Interviewer Expects
- Precise contrast: self-persisting object vs separate persistence interface
- Understanding of the coupling vs simplicity tradeoff
- A clear recommendation criterion (app complexity, testability, flexibility)
- Awareness both patterns can coexist across a codebase's different modules
Common Mistakes
- Claiming one pattern is strictly better in all cases
- Saying Active Record cannot be unit tested at all (it can, just with more friction)
- Confusing Repository with Data Mapper (a related but distinct pattern)
- Ignoring that Repository still needs something like Unit of Work for transactional writes
Best Answer (HR Friendly)
“Active Record puts the save/find/delete logic directly on the domain object, so it knows how to persist itself — quick to write but tightly coupled to the database. Repository pulls that logic out into a separate interface, so the domain object stays plain and the persistence details are isolated and easy to swap or fake in tests. I would reach for Active Record on a small CRUD app and Repository when the business logic is complex or the data source might change.”
Code Example
// Active Record: object persists itself
class ActiveRecordUser {
String id, name;
void save() { /* writes directly to the "users" table */ }
static ActiveRecordUser find(String id) { return new ActiveRecordUser(); }
}
// Repository: object is plain data, persistence is separate
class User {
String id, name;
}
interface UserRepository {
User findById(String id);
void save(User user);
}
class JdbcUserRepository implements UserRepository {
public User findById(String id) { return new User(); }
public void save(User user) { /* writes to the "users" table */ }
}Follow-up Questions
- When would you choose Active Record over Repository?
- How does testability differ between the two patterns?
- How does Data Mapper relate to Repository?
- Can a codebase mix both patterns for different modules?
MCQ Practice
1. The key structural difference between Active Record and Repository is?
Active Record objects persist themselves; Repository isolates persistence behind a separate interface.
2. Which pattern generally makes domain objects easier to unit test in isolation?
Repository keeps domain objects free of persistence logic, so they can be tested without a database, and the repository itself can be faked.
3. Active Record is generally the better fit for?
Active Record's simplicity shines in straightforward CRUD apps where coupling to the schema is an acceptable tradeoff.
Flash Cards
Active Record vs Repository, in one line? — Active Record: object persists itself. Repository: persistence lives in a separate interface.
Which couples domain objects to schema more? — Active Record.
Which is easier to unit test in isolation? — Repository, since domain objects stay persistence-agnostic.
When to pick Active Record? — Simple, CRUD-heavy apps where speed of development matters most.