Repository

The interface — a collection you can swap

A repository starts as an interface: a small set of collection-like methods that describe what you can do with your data, not how it's done. For a User, that's usually the CRUD-ish quartet plus any domain queries you actually need:

interface UserRepository {
  save(user: User): void;          // add or update
  findById(id: number): User | null;
  findAll(): User[];
  delete(id: number): void;
}

Notice there's no SQL, no HTTP, no file path — nothing about storage at all. The caller depends only on this interface. That's [[program-to-interfaces]]: your domain code is written against the abstraction, so any implementation that honors it can be dropped in.

Concrete implementations behind it

Now you write one or more classes that satisfy that interface, each backed by a different store:

• `SqlUserRepository` — turns findById(7) into SELECT * FROM users WHERE id = 7 and save(user) into an INSERT/UPDATE. It talks to a real database.
• `InMemoryUserRepository` — keeps a plain Map or array in memory. save pushes, findById looks up the key. Perfect for tests: no database required.
• `ApiUserRepository` — turns the same calls into HTTP requests: findById(7) becomes a GET /users/7, save(user) a POST /users.

All three are interchangeable because they honor the same UserRepository interface. The caller receives whichever one it's handed — usually via [[dependency-injection-and-ioc]] — and can't tell which. High-level code depending on an abstraction while the low-level storage details depend on that same abstraction is [[dependency-inversion]] in action.

Why bother — three concrete payoffs

• Testability — hand your service an InMemoryUserRepository in tests. No database to spin up, no network, no flakiness. Tests run in milliseconds and stay deterministic.
• One place for query logic — every way of fetching users lives inside the repository. Need a new query? It goes in one file, not scattered across a dozen call sites.
• Persistence-ignorant domain — your business rules read like business rules, not like database plumbing. The domain never imports a SQL driver or an HTTP client.

Repository vs DAO — close, but not the same

People mix these up. A DAO (Data Access Object) is usually one table, one class, offering thin CRUD that maps very closely to the database — it thinks in rows and tables. A Repository is more domain-oriented: it deals in whole business objects (aggregates), behaves like an in-memory collection, and may pull data from several tables — or even several sources — to hand you one complete object. Roughly: DAO speaks database, Repository speaks domain. In practice a Repository is often implemented using one or more DAOs underneath.

Reach for Repository when...

• You want to swap storage without touching business code — you're on Postgres today but want an in-memory fake for tests, or you foresee moving to a different store or a REST API later.
• Testing keeps dragging in a real database — an in-memory repository lets your service tests run fast, offline, and deterministically.
• Query logic is scattered — you want one home for all the ways your code fetches a given kind of object, instead of raw queries sprinkled across call sites.
• Your domain should stay persistence-ignorant — business rules that read like business rules, with no SQL or HTTP leaking in.

Skip it when...

• It's a tiny app with one data source that will never change — the extra interface and class are ceremony with no payoff.
• Your ORM already gives you a good-enough abstraction — if a repository would just forward straight to dbContext.Users or a Spring Data interface with nothing added, it's a pointless passthrough.
• You'd end up leaking the store anyway — if the only way to express your queries is to hand back an IQueryable or raw builder, the abstraction buys you nothing.