Would you always put a custom repository layer over EF Core? Explain when it helps and when it only adds indirection.

Repository pattern over EF Core: useful boundary or extra layer

Evaluates repositories by domain language, query ownership, and substitutability instead of treating them as a mandatory wrapper around DbSet.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

No, I would not always put a custom repository over EF Core. A repository helps when it represents an aggregate or business-oriented persistence boundary, such as loading an order with the state required for a transition and saving through one consistency boundary. It can also protect the core from provider details when substitution is realistic. For read-heavy endpoints, direct EF Core projections or focused query services are often clearer than forcing every query through a repository method.

Full answer below

Practice focus

EF Core, repositories, unit of work, aggregate persistence, query abstractions, testing, and leaky generic wrappers.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
I would not add a custom repository automatically. DbContext already provides unit-of-work behavior and DbSet provides collection-like access, so a generic CRUD wrapper often renames EF Core while hiding useful query features.
No, I would not always put a custom repository over EF Core. A repository helps when it represents an aggregate or business-oriented persistence boundary, such as loading an order with the state required for a transition and saving through one consistency boundary. It can also protect the core from provider details when substitution is realistic. For read-heavy endpoints, direct EF Core projections or focused query services are often clearer than forcing every query through a repository method.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I avoid returning IQueryable from a repository if the purpose is to hide persistence, because callers then build provider-specific queries anyway. I also avoid generic methods such as GetAll, Find, Update, and Delete that permit invalid aggregate usage. Tests should exercise business logic separately and use integration tests for important EF queries; mocking a repository does not prove translation, constraints, or transactions. The boundary should express intent and reduce coupling, not merely make DbContext mockable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating a generic repository because every project has one.
Returning IQueryable while claiming EF Core is hidden.
Mocking repositories instead of testing important SQL behavior.
Treating repository calls and remote calls as one transaction.

Would you always put a custom repository layer over EF Core? Explain when it helps and when it only adds indirection.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement