Skip to content

Latest commit

 

History

History
213 lines (133 loc) · 4.18 KB

Questions.md

File metadata and controls

213 lines (133 loc) · 4.18 KB

Q1 . EF Core already implements Repository (DbSet) and Unit of Work (DbContext). why Repository pattern needed.

EF Core already implements Repository (DbSet) and Unit of Work (DbContext). We add our own Repository/UoW only when we need abstraction, domain separation, testability, or complex business queries. Otherwise, it’s unnecessary boilerplate.

That single sentence already puts you ahead of most candidates.

Why EF Core Is Already Repository + UoW

EF Core Repository

  • DbSet<TEntity> → Repository
_context.Orders.Add(order);
_context.Orders.Find(id);

EF Core Unit of Work

  • DbContext → Unit of Work
_context.SaveChanges(); // transaction boundary

✔ Tracks changes ✔ Commits or rolls back ✔ Manages transactions

👉 So yes, EF Core already does both.

Then Why Do People Add Repository + UoW Again?

1️⃣ To Protect the Domain (Onion / Clean Architecture)

Without repository:

Application → EF Core → SQL

With repository:

Application → Interface → Infrastructure(EF)

👉 Domain/Application should not depend on EF Core.

2️⃣ To Avoid EF Core Leaking Everywhere

If you inject DbContext everywhere:

  • Include()
  • AsNoTracking()
  • LINQ everywhere

Business logic becomes ORM-aware, which is bad design.

Repository:

  • Exposes intent-based methods
GetActiveOrdersForCustomer(id)

not:

_context.Orders.Where(...)

3️⃣ For Better Testability

With repository:

mockRepo.Setup(x => x.GetById(1)).Returns(order);

Without repository:

  • Need InMemory DB
  • Slower
  • Less deterministic

4️⃣ For Complex Queries / Aggregates

Repositories make sense when:

  • Aggregate roots
  • Domain-specific queries
  • Multiple tables involved
Order GetOrderWithPaymentsAndInvoices(int id);

5️⃣ To Control Transactions Explicitly (UoW)

EF Core auto transaction is fine until:

  • Multiple DbContexts
  • Multiple SaveChanges
  • External calls involved

UoW gives:

  • Clear transaction boundary
  • One commit point

When You SHOULD NOT Create Custom Repository/UoW ❌

This is the killer interview insight.

❌ Simple CRUD application ❌ Thin service layer ❌ Just passing DbSet calls ❌ Generic repository wrapping DbSet blindly

GetAll()
Add()
Update()
Delete()

👉 This becomes an anti-pattern.

Microsoft & DDD Community View (Important)

❝ Generic repository over EF Core is usually unnecessary and harmful ❞ — Microsoft Docs / Jimmy Bogard

They recommend:

  • Use DbContext directly
  • Add repositories only for aggregates

Correct Real-World Approach (Best Practice)

Option A: Small / Medium App

✔ Use EF Core directly ✔ No repository ✔ DbContext injected into services

Option B: Enterprise / DDD / Onion

✔ Repository per aggregate ✔ No generic repository ✔ DbContext hidden in Infrastructure ✔ UoW only if needed

How to Explain This in Interview (30 Seconds)

“EF Core already provides repository and unit of work through DbSet and DbContext. Creating our own Repository/UoW is not mandatory and can become boilerplate. We introduce them only when we need domain isolation, clean architecture boundaries, complex queries, or better testability. Otherwise, using DbContext directly is perfectly fine.”

Interview Trap Questions & Smart Answers

Q: Do you always implement Repository with EF Core? 👉 No, only when architectural boundaries or domain complexity require it.

Q: Is generic repository a good idea? 👉 Usually no with EF Core.

Q: What is better than generic repository? 👉 Specific repositories per aggregate root.

Final One-Line Power Answer ⭐

“EF Core already implements Repository and Unit of Work, so we add our own only when we need abstraction and architectural boundaries—otherwise it’s unnecessary complexity.”

If you want next, I can:

  • Give exact interview wording
  • Explain anti-patterns with examples
  • Show how senior architects design this
  • Compare EF Core vs Dapper decision

Just tell me 👍