Have you ever opened an ASP.NET Core solution and wondered why it contains multiple projects named Domain, Application, Infrastructure, and API?

Why not simply put everything inside controllers and services?

And why do developers introduce interfaces when they could directly use Entity Framework Core?

The answer lies in one important concept: separation of concerns and control over dependencies.

Let’s understand Clean Architecture through a practical example.

1. What Is Clean Architecture, Really?

Clean Architecture, introduced by Robert C. Martin, is an architectural approach that organizes software around its business rules rather than its technical implementation details.

Imagine we’re developing an e-commerce application.

Our system needs to:

• Create and manage orders.
• Calculate order totals.
• Save orders in a database.
• Send confirmation emails.

Some of these are business responsibilities (creating and validating orders), while others are technical responsibilities (database access and email delivery).

The objective is simple:

Business logic should remain independent of frameworks, databases, and external services.

This way, changing SQL Server to PostgreSQL, for example, doesn’t require rewriting how orders are created or validated.

2. The Problem: Tightly Coupled Code

Consider this simplified ASP.NET Core controller:

[HttpPost]
public async Task<IActionResult> CreateOrder(
    CreateOrderRequest request)
{
    var order = new Order
    {
        Total = request.Quantity * request.Price
    };
    _context.Orders.Add(order);
    await _context.SaveChangesAsync();
    return Ok(order);
}

It works. So what’s the problem?

Our controller is handling HTTP communication, calculating the order total, and managing persistence.

As business requirements grow, controllers can become difficult to maintain and business logic becomes harder to reuse and test independently.

Clean Architecture helps us separate these responsibilities.

3. Understanding the Four Layers

A common ASP.NET Core Clean Architecture implementation consists of four layers.

Domain — The heart of the application

The Domain layer contains business entities and rules.

For example:

public class Order
{
    public decimal Total { get; private set; }

    public Order(int quantity, decimal price)
    {
        if (quantity <= 0 || price <= 0)
            throw new ArgumentException(
                "Invalid order values");
        Total = quantity * price;
    }
}

Notice something important: there is no EF Core, SQL Server, or ASP.NET Core dependency here.

The entity only knows its business rules.

In a real e-commerce system, the price would normally come from trusted product data rather than directly from the client’s request.

Application — What the system can do

The Application layer defines use cases such as:

• CreateOrder
• CancelOrder
• GetOrderById

It coordinates business operations without knowing how infrastructure works.

public class CreateOrderHandler
{
    private readonly IOrderRepository _repository;
    public CreateOrderHandler(
        IOrderRepository repository)
    {
        _repository = repository;
    }
    public async Task Handle(
        int quantity,
        decimal price)
    {
        var order = new Order(quantity, price);
        await _repository.AddAsync(order);
    }
}

The repository contract is defined inside the Application layer:

public interface IOrderRepository
{
    Task AddAsync(Order order);
}

Why an interface? This brings us to the most important principle in Clean Architecture.

Infrastructure — How technical operations work

Infrastructure contains concrete implementations for database access, email services, external APIs, and similar concerns.

For example:

public class OrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;
    public OrderRepository(AppDbContext context)
    {
        _context = context;
    }
    public async Task AddAsync(Order order)
    {
        await _context.Orders.AddAsync(order);
        await _context.SaveChangesAsync();
    }
}

Here, Entity Framework Core manages database persistence.

The important detail is that Infrastructure implements the interface defined by Application.

Application doesn’t depend on the concrete repository.

Presentation — How users interact with the application

The Presentation layer exposes the use cases through ASP.NET Core controllers or Minimal APIs.

[HttpPost]
public async Task<IActionResult> CreateOrder(
    CreateOrderRequest request)
{
    await _handler.Handle(
        request.Quantity,
        request.Price);
   return Ok();
}

The controller receives the request and delegates the operation to Application.

It doesn’t contain persistence logic or decide how the order is saved.

4. The Golden Rule: Dependency Inversion

The most important rule of Clean Architecture is:

Dependencies should point inward, toward the business core.

The relationships generally look like this:

API ─────────────→ Application
 │                       │
 │                       ↓
 │                    Domain
 ↓
Infrastructure ───→ Application
       │
       └──────────→ Domain

Why does Infrastructure depend on Application?

Because Application defines IOrderRepository, and Infrastructure implements it.

Without dependency inversion:

Application → SqlOrderRepository

With dependency inversion:

Application → IOrderRepository
                    ↑
               OrderRepository
               (Infrastructure)

The Application layer defines what it needs, while Infrastructure provides how it works.

This is the Dependency Inversion Principle (the D in SOLID).

Dependency Inversion vs. Dependency Injection

They sound similar, but they’re different.

• Dependency Inversion is a design principle describing how dependencies should be organized.
• Dependency Injection is a technique for supplying dependencies to classes.

In ASP.NET Core, we connect the interface to its implementation using the built-in DI container:

builder.Services.AddScoped<
    IOrderRepository,
    OrderRepository>();

Now, when CreateOrderHandler requests IOrderRepository, ASP.NET Core provides the registered implementation.

This allows the Application layer to stay independent of the actual database implementation.

5. What Happens When a Request Arrives?

Let’s follow the complete execution of POST /api/orders.

Client sends HTTP request
          ↓
OrdersController
(Presentation)
          ↓
CreateOrderHandler
(Application)
          ↓
Order entity
(Domain — validates rules)
          ↓
IOrderRepository
(Application contract)
          ↓
OrderRepository
(Infrastructure — EF Core)
          ↓
SQL Server

This diagram represents runtime execution flow, not source-code dependency direction.

At runtime, Application calls Infrastructure through an interface. At compile time, Infrastructure references Application.

That distinction is fundamental to understanding Clean Architecture.

6. Why Is Clean Architecture Useful?

The main benefits become visible as your application grows.

Maintainability: Each layer has a clear responsibility, making code easier to understand and modify.

Testability: Business rules can be tested without starting the web server or connecting to a real database.

Flexibility: Infrastructure implementations can change while the business-facing contracts remain stable.

Reduced coupling: Controllers don’t need to understand database operations, and domain entities don’t need to understand HTTP.

However, Clean Architecture doesn’t eliminate all complexity. Database migrations, transactions, performance, and integration concerns still require careful engineering.

7. Common Mistakes to Avoid

Mistake 1: Thinking Clean Architecture is just four folders.

Creating separate projects doesn’t guarantee a clean design. The important part is enforcing dependency boundaries.

Mistake 2: Putting business rules inside controllers.

Controllers should focus on HTTP concerns and delegate business operations to application use cases.

Mistake 3: Creating interfaces for everything.

Not every class needs an interface. Introduce abstractions when they establish useful boundaries.

Mistake 4: Thinking CQRS or MediatR is mandatory.

Clean Architecture can work perfectly well without either. They are additional patterns and tools, not requirements.

Final Thoughts

Clean Architecture isn’t about writing more code or creating more projects.

It’s about building an application where business logic is the priority, and technical details remain replaceable implementation choices.

The next time you design an ASP.NET Core application, don’t start by asking:

“How many layers should I create?”

Instead, ask:

“Which parts of my application represent business decisions, and which parts are just implementation details?”

That’s where good architectural thinking begins.

When someone decides to learn .NET, the first thing they usually search for is:

“.NET developer roadmap.”

And then comes the problem.

You find a giant diagram with C#, ASP.NET Core, EF Core, SQL, Docker, Azure, design patterns, microservices, testing, CI/CD, Redis, RabbitMQ…

And suddenly learning .NET feels less like a roadmap and more like preparing for a final boss.

I’ve been working through my own .NET roadmap, and one thing became very clear:

A good roadmap is not about learning everything. It is about learning things in the right order.

Here is how I would approach it.

1. Don’t Start With ASP.NET Core

Yes, I said it.

A lot of people start their .NET journey by creating an API:

app.MapGet("/users", () => users);

It works.

Great.

But then something slightly more complicated appears and suddenly we don’t understand what C# is actually doing for us.

Before becoming an ASP.NET Core developer, become comfortable with C# itself.

And I don’t mean stopping after:

if
for
while
class
interface

Go deeper.

Understand the difference between a class and a struct.

Understand value types and reference types.

Understand what ref, out and in actually mean.

Learn why strings behave differently from many other reference types.

Understand immutability.

Learn the difference between shallow and deep copying.

Understand records and with expressions.

And eventually, learn a little about what happens underneath your code:

• Stack and heap
• Garbage Collector
• Boxing and unboxing
• CLR
• Object lifetime

You don’t need to become a runtime engineer.

But you should stop seeing C# as magic.

That’s the first milestone.

2. Learn the Parts of C# That Make Modern .NET Feel Like .NET

Once the fundamentals are comfortable, move into the features you will see everywhere in real projects.

Delegates.

Action.

Func.

Predicate.

Events.

Lambdas.

At first, things like this can look strange:

Func<int, int, int> add = (a, b) => a + b;

But later you realize that delegates and lambdas are everywhere.

LINQ uses them.

Events use them.

Framework APIs use them.

Dependency injection configurations use them.

Once you understand them, a lot of .NET suddenly becomes easier to read.

3. Don’t Just “Learn LINQ”

LINQ deserves its own stage.

Most developers quickly learn:

users.Where(x => x.IsActive).ToList();

But LINQ is much bigger than Where().

Learn:

Select

SelectMany

OrderBy

GroupBy

Any

All

Skip

Take

Join

And especially learn this distinction:

IEnumerable<T>

vs.

IQueryable<T>

Because once Entity Framework Core enters the picture, that difference matters a lot.

You should start asking questions like:

Is this operation happening in memory?

or

Will this become SQL?

That’s when you’re no longer just memorizing LINQ methods.

You’re reasoning about your application.

4. Async/Await: Don’t Stop at the Syntax

Most tutorials teach async like this:

await DoSomethingAsync();

And then move on.

That’s not enough.

Learn what a Task actually represents.

Understand:

Task.WhenAll()

and:

Task.WhenAny()

Understand why this:

.Result

can be very different from:

await

Learn when parallelizing work makes sense and when it doesn’t.

Understand cancellation tokens.

Understand why asynchronous programming is so important for server applications.

You don’t need to memorize the internals of the Task Parallel Library.

But you should understand what your program is doing when it hits await.

5. Learn Memory Before You Think You Need It

This is one of those topics developers often postpone.

And I understand why.

Span<T> isn't exactly the first thing you need when building a Todo API.

But eventually, understanding memory makes you a much stronger .NET developer.

Start with:

IDisposable

Then understand:

using

Learn why some objects need deterministic cleanup.

Then slowly explore concepts such as:

Span<T>
Memory<T>
ArrayPool<T>

Again, don’t turn your roadmap into a PhD in memory management :)

The goal is awareness.

When performance problems eventually appear, these concepts won’t feel completely foreign.

6. Now Learn ASP.NET Core

Now the framework starts making much more sense.

Learn how an HTTP request travels through your application.

Learn:

• Routing
• Controllers
• Minimal APIs
• Middleware
• Dependency Injection
• Configuration
• Logging
• Validation
• Authentication
• Authorization
• Exception handling

And don’t turn this into:

Controllers vs Minimal APIs: WHICH ONE WINS?

Both exist for a reason.

Minimal APIs can be excellent for small APIs, microservices, prototypes or endpoints where ceremony adds little value.

Controllers can be much easier to organize when applications become larger.

The goal isn’t to join a team.

The goal is to understand the trade-offs.

7. Then Learn Entity Framework Core Properly

At first EF Core looks beautiful.

var users = await context.Users.ToListAsync();

Database done.

Except… not really.

This is where another level of learning begins.

Understand what a DbContext represents.

Learn entity relationships.

Learn migrations.

Learn tracking vs no-tracking queries.

Understand:

Include()

Learn projections.

Understand when queries are executed.

And please learn to recognize this kind of problem:

var users = await context.Users.ToListAsync();
var activeUsers = users.Where(x => x.IsActive);

versus:

var activeUsers = await context.Users
    .Where(x => x.IsActive)
    .ToListAsync();

Those two pieces of code may produce the same result.

They don’t necessarily do the same amount of work.

That distinction matters.

8. Build Something Before Adding More Boxes to the Roadmap

This part is important.

Stop learning for a moment.

Build.

Not another application where the tutorial tells you what to type.

Build something where you make the decisions.

Add authentication.

Add pagination.

Add filtering.

Handle errors.

Add validation.

Use a real database.

Write tests.

Refactor ugly code.

Break something.

Fix it.

Because there is a point where another 4-hour course gives you less value than 30 minutes debugging your own mistake.

9. Only Then Move Toward Architecture

This is where roadmaps usually become dangerous.

People see:

Clean Architecture.

CQRS.

DDD.

Microservices.

Event-driven architecture.

And suddenly their Todo application has 14 projects, 37 interfaces and a message broker.

Architecture should solve problems.

Not create impressive folder structures.

Start with separation of concerns.

Understand dependency direction.

Understand why business logic shouldn’t live everywhere.

Learn SOLID.

Learn common design patterns.

Understand layered architecture.

Then explore Clean Architecture.

Later, study things like CQRS, event-driven architecture and microservices.

But learn the problem first.

Then learn the architecture that solves it.

Not the other way around.

10. Learn the Things That Make Code Production-Ready

At some point, writing code that works is no longer enough.

Now your roadmap should include:

Testing.

Logging.

Security.

Performance.

Caching.

Docker.

CI/CD.

Observability.

Git.

Code reviews.

Database optimization.

API versioning.

Background processing.

Messaging.

And eventually cloud platforms.

This is where you start moving from:

“I can build a .NET application.”

to:

“I understand how a .NET application survives in production.”

Those are very different skills.

The Roadmap Is Not a Checklist

This is probably the biggest thing I’ve learned while following my own roadmap.

You never really finish a topic.

I studied LINQ.

Then EF Core made me understand LINQ differently.

I studied async programming.

Then web development gave it more context.

I studied memory management.

Then performance made those concepts useful.

That’s how learning software engineering works.

You keep returning to the same concepts but every time, you understand them at a deeper level.

So my .NET roadmap isn’t:

Learn → Check the box → Never touch again.

It’s more like:

Learn → Build → Struggle → Understand → Revisit → Improve.

And if you’re starting your .NET journey, that’s probably the most important thing to remember.

Don’t try to learn the entire ecosystem.

Don’t chase every new library.

Don’t copy someone else’s 200-item roadmap.

Build strong foundations.

Add one layer at a time.

And most importantly:

Don’t learn .NET just to know how to write .NET code.

Learn enough to understand why the code works the way it does.

When I work on a reasonably large ASP.NET Core API, I still like opening a ProductsController, seeing the actions, the dependencies, and having a clear structure.

But that doesn’t mean Minimal APIs are useless.

In some cases, they actually make a lot of sense.

So, What Is a Minimal API?

With controllers, an endpoint usually looks like this:

[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _service;
    public ProductsController(IProductService service)
    {
        _service = service;
    }
    [HttpGet("{id}")]
    public async Task<IActionResult> Get(int id)
    {
        var product = await _service.GetByIdAsync(id);
        return product is null
            ? NotFound()
            : Ok(product);
    }
}

With Minimal APIs, the same idea can become:

app.MapGet("/api/products/{id}", async (
    int id,
    IProductService service) =>
{
    var product = await service.GetByIdAsync(id);
   return product is null
        ? Results.NotFound()
        : Results.Ok(product);
});

The main difference is simple.

With controllers:

Route → Controller → Action → Service

With Minimal APIs:

Route → Handler → Service

The controller is no longer required.

Minimal Does Not Mean “Everything in Program.cs”

This is probably the part that made me dislike Minimal APIs at first.

When you see code like:

app.MapGet(...);
app.MapPost(...);
app.MapPut(...);
app.MapDelete(...);

it’s easy to imagine Program.cs becoming a 2,000-line monster.

But that’s not a Minimal API requirement.

You can still organize your endpoints:

Endpoints/
├── ProductEndpoints.cs
├── OrderEndpoints.cs
└── UserEndpoints.cs

and keep Program.cs simple:

app.MapProductEndpoints();
app.MapOrderEndpoints();
app.MapUserEndpoints();

So Minimal APIs remove some HTTP ceremony.

They don’t remove architecture.

When Do They Actually Make Sense?

This is where I understand their value.

Imagine a small microservice exposing only:

POST /notifications
GET  /notifications/{id}
GET  /health

Do we really need an entire controller structure for three endpoints?

Maybe not.

Minimal APIs are great for:

• small APIs
• microservices
• internal endpoints
• simple CRUD services
• vertical slice architectures

For a large API with many conventions and a big team, I might still prefer controllers.

And that’s fine.

Controllers vs Minimal APIs Is Not a Competition

I don’t think the question should be:

“Should we stop using controllers?”

A better question is:

“Does this endpoint actually need a controller?”

Sometimes the answer is yes.

Sometimes this is enough:

app.MapGet("/health", () => "OK");

You can even use both in the same application:

app.MapControllers();
app.MapGet("/health", () => "OK");

My Take

Minimal APIs still aren’t my default choice for every project.

I like the structure and conventions that controllers give me.

But I also understand why Minimal APIs exist now.

They’re not about writing the smallest amount of code possible.

They’re about avoiding structure when that structure isn’t actually giving us much value.

So no, Minimal APIs haven’t converted me.

But for the right project?

I’d definitely use them.

var user = new User();

But here is an important question:

Who removes this object from memory when we no longer need it?

In languages like C or C++, developers often have to manually free memory. But in C#, this job is mostly handled automatically by the Garbage Collector, usually called the GC.

What Is the Garbage Collector?

The Garbage Collector is a part of the .NET runtime that manages memory for us.

Its main job is simple:

Find objects that are no longer used and remove them from memory.

For example:

public void CreateUser()
{
    var user = new User();
}

When the method finishes, the variable user is gone. If nothing else is referencing that object, the Garbage Collector can clean it later.

But there is one important thing to understand:

The GC does not clean memory immediately when the object is no longer used. It decides the best time to do it.

Why Do We Need the Garbage Collector?

Without the Garbage Collector, we would have to manually release memory every time we finish using an object.

That can easily cause problems like:

• Memory leaks
• Crashes
• Using objects after they were already destroyed
• Bad memory management

The Garbage Collector makes memory management safer and easier for developers.

In most cases, we do not need to think about removing normal objects from memory. The GC will take care of them automatically.

Managed Memory vs External Resources

The Garbage Collector is very good at cleaning managed memory.

Managed memory means normal objects created and managed by .NET, like:

var list = new List<string>();
var user = new User();

But sometimes, an object uses something outside normal .NET memory, such as:

• Files
• Database connections
• Network connections
• Streams

Example:

var file = new FileStream("test.txt", FileMode.Open);

These resources are not just simple C# objects. They are connected to the operating system.

This is where cleanup becomes more important.

What Is a Finalizer?

A finalizer is a special method that runs before an object is removed by the Garbage Collector.

It looks like this:

public class MyResource
{
    ~MyResource()
    {
        // Cleanup logic
    }
}

The method ~MyResource() is called a finalizer.

Its purpose is to give the object one last chance to clean something before it is removed from memory.

Should We Use Finalizers Often?

Usually, no.

Finalizers are rarely written manually in modern C# code.

Why?

Because finalizers make the cleanup process slower and more complex.

When an object has a finalizer, the Garbage Collector cannot remove it directly. It first needs to call the finalizer, then the object will be cleaned later.

So finalizers should only be used in special cases, usually when a class directly owns unmanaged resources.

For most real projects, we use something better: IDisposable.

IDisposable Is the Preferred Way

When a class uses resources like files, streams, or database connections, it should implement IDisposable.

Example:

public class FileService : IDisposable
{
    private FileStream fileStream;

    public FileService()
    {
        fileStream = new FileStream("test.txt", FileMode.Open);
    }
    public void Dispose()
    {
        fileStream.Dispose();
    }
}

Then we can use it like this:

using var service = new FileService();

The using statement automatically calls Dispose() when the object is no longer needed.

This is better because the cleanup happens immediately and predictably.

Simple Rule to Remember

If your object only uses normal C# objects, you usually do not need to do anything.

The Garbage Collector will handle it.

But if your object uses files, streams, database connections, or external resources, you should use IDisposable and the using statement.

Finalizers exist, but they are for rare and advanced cases.

Conclusion

The Garbage Collector is one of the most important features of .NET. It helps developers avoid many memory management problems by automatically cleaning unused objects.

But the GC does not replace good resource management.

For normal objects, let the Garbage Collector do its job.

For external resources, use Dispose() and using.

And remember:

Finalizers exist, but in most real projects, IDisposable is the better tool.

Structs are stored on the Stack, and Classes are stored on the Heap.

It’s simple.

It’s easy to remember.

And… it’s not entirely true.

Let’s fix that in less than 3 minutes.

The Stack: Fast and Temporary

Think of the stack as your method’s workspace.

When a method starts, it gets a small area to store local variables and parameters.

void Calculate()
{
    int x = 10;
    int y = 20;
}

When Calculate() finishes, both x and y disappear automatically.

No cleanup.
No Garbage Collector.
Just incredibly fast memory management.

The Heap: Where Objects Live

Now look at this:

Person person = new Person();

Many developers think person is on the Heap.

Not exactly.

The object is on the Heap.

The variable person is just a reference that points to that object.

You can imagine it like this:

Stack                    Heap
-------                  ----------------
person  ------------->   Person Object

The variable knows where the object is — it doesn’t contain the object itself.

The Rule That Actually Matters

Instead of memorizing:

❌ Struct → Stack

❌ Class → Heap

Remember this instead:

• Value types are copied by value.
• Reference types are copied by reference.

That’s the real difference.

For example:

int x = 10;
int y = x;

y = 20;

x is still 10 because the value was copied.

Now compare that with a class:

Person p1 = new Person();
Person p2 = p1;

p2.Name = "Alice";

p1.Name is also "Alice" because both variables point to the same object.

The Misconception

Here’s the part that surprises many developers.

Consider this struct:

struct Point
{
    public int X;
    public int Y;
}

Now place it inside a class:

class Car
{
    public Point Position;
}

Is Point on the Stack?

No.

Since it’s a field inside a heap-allocated object (Car), the struct is also stored in the Heap.

So the statement:

“Structs are always stored on the Stack.”

is simply false.

Takeaway

The Stack and the Heap are memory areas.

struct and class are language features.

They are related, but they’re not the same concept.

The best mental model is this:

• Stack and Heap describe where memory is allocated.
• Value and Reference types describe how data is copied and passed around.

Once you understand that distinction, concepts like boxing, garbage collection, ref, in, out, and even performance optimizations become much easier to grasp.

Sometimes replacing one incorrect sentence with the right mental model is worth more than memorizing ten definitions.

@foreach (var user in Users)
{
    <UserCard User="user" />
}

Simple. Clean. Works perfectly.

A while ago, I was working on a page that displayed a dynamic list of items. Everything seemed fine until I started testing scenarios where items could be added, removed, or reordered.

That’s when some strange behavior appeared:

• An input field would unexpectedly lose focus while I was typing.
• Components seemed to keep state that belonged to a different item.
• Expanded sections would collapse after a list update.
• UI state appeared to “move” from one item to another.

The code looked correct, but the behavior felt completely random.

The culprit :) ?

A small Blazor directive I had ignored:

@key

And once I understood what it actually does, many rendering mysteries suddenly made sense.

How Blazor Thinks

When a component re-renders, Blazor tries to be smart.

Instead of destroying and recreating every DOM element and component, it compares the old render tree with the new one and reuses as much as possible.

This optimization is great for performance.

However, Blazor often identifies elements by their position in a list.

Consider this example:

@foreach (var person in People)
{
    <PersonCard Person="person" />
}

Initially the list contains:

Alice
Bob
Charlie

Now imagine we insert a new item at the beginning:

People.Insert(0, new Person("David"));

The new list becomes:

David
Alice
Bob
Charlie

From your perspective, a new item was added.

From Blazor’s perspective, every position changed.

As a result, Blazor may reuse existing component instances for different people.

That means:

• The component that represented Alice may now represent David.
• The component that represented Bob may now represent Alice.
• Internal state may be reused unexpectedly.

And that’s where weird bugs begin.

Enter @key

The solution is surprisingly simple:

@foreach (var person in People)
{
    <PersonCard
        @key="person.Id"
        Person="person" />
}

Now Blazor no longer tracks components by position.

Instead, it tracks them by identity.

You’re effectively telling Blazor:

This component belongs to this specific object. Preserve that relationship.

If a new item is inserted, Blazor knows exactly which component belongs to which person.

No confusion.

No state swapping.

No surprises.

A Real-World Example

Let’s say you’re building a form.

@foreach (var child in Children)
{
    <input value="@child.Name" />
}

A user starts typing in the second input.

Meanwhile, another user adds a new child, causing the list to refresh.

Without @key, Blazor may reuse DOM elements and component instances based on position.

The result can be:

• Lost cursor position
• Lost focus
• Data appearing in the wrong place

Adding a key fixes the issue:

@foreach (var child in Children)
{
    <input
        @key="child.Id"
        value="@child.Name" />
}

Now each input remains attached to the correct child regardless of how the list changes.

When Should You Use @key?

You should strongly consider using @key whenever:

1. Rendering Dynamic Lists

@foreach (var product in Products)
{
    <ProductCard
        @key="product.Id"
        Product="product" />
}

2. Items Can Be Added or Removed

Products.Insert(0, newProduct);
Products.Remove(product);

3. Components Have Internal State

<UserEditor
    @key="user.Id"
    User="user" />

Stateful components are particularly vulnerable to incorrect reuse.

4. User Experience Matters

Forms, editable grids, drag-and-drop interfaces, and dashboards are all excellent candidates.

When You Don’t Need It

Not every list requires @key.

For example:

@foreach (var month in Months)
{
    <span>@month</span>
}

If the list never changes and contains simple elements, adding keys usually brings little benefit.

The important thing is understanding when identity matters.

A Common Mistake

I’ve seen developers do this:

@key="Guid.NewGuid()"

This is almost always wrong.

Why?

Because the value changes on every render.

Blazor sees a completely new key every time and destroys then recreates the component from scratch.

You lose the very optimization that @key was designed to provide.

Keys should be stable.

Good examples:

@key="user.Id"
@key="product.Id"
@key="order.OrderNumber"

Bad examples:

@key="Guid.NewGuid()"
@key="DateTime.Now"

The Lesson

@key is one of those Blazor features that looks insignificant until you understand the problem it solves.

Most applications work perfectly without it — until lists become dynamic, components become stateful, and users start interacting with your UI.

Then suddenly a single line:

@key="item.Id"

can save hours of debugging.

If you’re building interactive Blazor applications and you’re not paying attention to component identity, you’re likely one bug away from discovering why @key exists.

And when that day comes, you’ll be glad you know it.

• List
• Dictionary
• HashSet
• GroupBy

But there’s one LINQ feature that almost nobody talks about:

ToLookup()

Honestly, many developers go years without using it once.

And that’s surprising because ILookup<TKey, TValue> solves a very common problem elegantly.

The Problem: One Key → Multiple Values

A Dictionary<TKey, TValue> works when:

• one key maps to one value

Example:

Dictionary<int, User>

But real applications often need:

• one department → many employees
• one category → many products
• one parent → many children
• one order → many items

Most developers solve this manually:

Dictionary<int, List<Employee>>

It works.

But .NET already has a structure designed exactly for this scenario:

ILookup<TKey, TValue>

Creating a Lookup

Imagine this model:

public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public int DepartmentId { get; set; }
}

Now let’s group employees by department:

var employees = new List<Employee>
{
    new() { Id = 1, Name = "Alice", DepartmentId = 1 },
    new() { Id = 2, Name = "Bob", DepartmentId = 1 },
    new() { Id = 3, Name = "Charlie", DepartmentId = 2 }
};

ILookup<int, Employee> lookup =
    employees.ToLookup(e => e.DepartmentId);

Now:

• key = DepartmentId
• value = employees belonging to that department

Accessing Values

var hrEmployees = lookup[1];

Result:

Alice
Bob

You immediately get all employees for department 1.

No filtering.
No manual grouping.
No dictionary initialization.
No ContainsKey.

The Difference Between GroupBy() and ToLookup()

This is where many developers get confused.

At first glance, they look similar.

employees.GroupBy(e => e.DepartmentId)

vs

employees.ToLookup(e => e.DepartmentId)

But internally, they behave differently.

GroupBy() → Deferred Execution

GroupBy() is lazy.

It does not immediately build the groups.

The query executes when you enumerate it.

var grouped = employees.GroupBy(e => e.DepartmentId);

Nothing happens yet.

Execution occurs later:

foreach (var group in grouped)
{
}

ToLookup() → Immediate Execution

ToLookup() executes immediately.

var lookup = employees.ToLookup(e => e.DepartmentId);

The lookup structure is built instantly and cached in memory.

This makes repeated access very efficient.

Why ToLookup() Can Be Faster

Imagine this code:

foreach (var department in departments)
{
    var employeesInDepartment =
        employees.Where(e => e.DepartmentId == department.Id);
// Process employees
}

This repeatedly scans the entire employee list.

Now compare it with:

var lookup = employees.ToLookup(e => e.DepartmentId);
foreach (var department in departments)
{
    var employeesInDepartment = lookup[department.Id];
    // Process employees
}

Now access becomes extremely fast because the grouping is already indexed.

This is one of the best use cases for ToLookup().

ILookup vs Dictionary<TKey, List<T>>

A lot of developers ask:

“Why not just use Dictionary<int, List<Employee>>?”

Fair question.

Both solve similar problems.

But ILookup has some nice advantages.

1. Cleaner Creation

Dictionary approach:

var dictionary = employees
    .GroupBy(e => e.DepartmentId)
    .ToDictionary(
        g => g.Key,
        g => g.ToList());

Lookup approach:

var lookup = employees.ToLookup(e => e.DepartmentId);

Much simpler.

2. Missing Keys Are Safe

Dictionary:

dictionary[999]

Throws:

KeyNotFoundException

Lookup:

lookup[999]

Returns:

Empty collection

This is one of the most underrated benefits.

3. Immutable Structure

ILookup is read-only.

You cannot accidentally modify it after creation.

That makes it safer for:

• caching
• read-heavy operations
• query results
• shared data

When Should You Use ToLookup()?

ToLookup() shines when:

• you need repeated grouped access
• the data is mostly read-only
• you want fast retrieval by key
• one key maps to multiple values
• you want cleaner code than Dictionary<TKey, List<T>>

Examples:

• grouping notifications by user
• products by category
• orders by customer
• logs by severity
• children by parent ID

Why Most Developers Never Use It

Honestly?

Because it’s rarely taught.

Most tutorials focus on:

• List
• Dictionary
• HashSet

And when developers need grouping, they usually stop at:

GroupBy()

ILookup sits in that strange area of .NET:

• extremely useful
• very clean
• surprisingly unknown

Final Thoughts

ToLookup() is not something you’ll use every day.

But when you need:

• one-to-many relationships
• fast grouped access
• clean read-only grouping

…it becomes one of the nicest LINQ features available.

Sometimes the best parts of .NET are the APIs nobody talks about enough.

if (obj is string text)
{
    Console.WriteLine(text);
}

But modern C# turned pattern matching into something much bigger.

Today, pattern matching is one of the cleanest ways to:

• remove unnecessary null checks
• reduce casting
• simplify conditions
• write more expressive code

And the best part?

Most developers still use only 10% of it.

Let’s explore the most useful pattern matching features introduced from C# 7 to C# 12.

C# 7 — The Beginning

Type Pattern

if (obj is string text)
{
    Console.WriteLine(text.Length);
}

Before:

if (obj is string)
{
    string text = (string)obj;
}

C# 7 introduced:

• type checking
• casting
• variable declaration

…all in one line.

This was the start of modern pattern matching.

C# 8 — Cleaner Switch Logic

Switch Expressions

Before:

switch (status)
{
    case "Done":
        return "Finished";
    case "Pending":
        return "Waiting";
    default:
        return "Unknown";
}

After:

return status switch
{
    "Done" => "Finished",
    "Pending" => "Waiting",
    _ => "Unknown"
};

This feature immediately made code:

• shorter
• cleaner
• easier to read

You’ll now find switch expressions everywhere in modern .NET applications.

C# 9 — The Real Game Changer

C# 9 introduced the patterns most developers use today.

Non-null Pattern

if (user is { } u)
{
    Console.WriteLine(u.Name);
}

Equivalent to:

if (user != null)

But cleaner because it also creates a local variable.

This pattern became extremely popular in:

• Blazor
• ASP.NET Core
• APIs
• services

Logical Patterns

if (age is > 18 and < 30)
{
    Console.WriteLine("Young adult");
}

if (status is "Done" or "Completed")
{
    Console.WriteLine("Finished");
}

if (value is not null)
{
    Console.WriteLine("Exists");
}

These patterns make conditions read almost like English.

Property Patterns

if (user is { IsActive: true, Role: "Admin" })
{
    // valid admin
}

Instead of writing:

if (user != null &&
    user.IsActive &&
    user.Role == "Admin")

You simply describe the shape of valid data.

That’s the real power of pattern matching.

Nested Property Patterns

if (order is { Customer.Name: "Wiem" })
{
    // matched
}

This allows deep object validation without complicated null checks.

C# 11 — List Patterns

C# 11 added support for collection matching.

Exact Match

if (numbers is [1, 2, 3])
{
    Console.WriteLine("Exact match");
}

Start / End Matching

if (numbers is [1, ..])
{
    Console.WriteLine("Starts with 1");
}


if (numbers is [.., 10])
{
    Console.WriteLine("Ends with 10");
}

This feature is incredibly useful for:

• parsing
• routing
• command processing
• data validation

Real-World Example

Here’s a practical example combining multiple patterns:

if (request is
    {
        User: { IsActive: true, Role: "Admin" },
        Total: > 100
    } validRequest)
{
    Process(validRequest);
}

In a single expression, we:

• validate the user
• check the role
• verify activity status
• validate the total
• create a strongly typed variable

Without nested conditions.
Without extra null checks.
Without casting.

Final Thought

Pattern matching is more than syntax sugar.

It changes the way you think about conditions.

Instead of writing:
“How do I check this?”

You start writing:
“What does valid data look like?”

And that small mindset shift makes modern C# code dramatically cleaner.

But if you ask:

“On which thread does this run?”
“When is a thread created?”
“What does a Task really represent?”

Things get… blurry.

This post is not about syntax.

It’s about building a correct mental model of how .NET executes your code.

1. Threads — The Physical Reality

At the lowest level, everything runs on a thread.

👉 A thread is:

• an OS-level execution unit
• scheduled by the operating system
• relatively expensive to create and manage

If you do this:

new Thread(() => DoWork()).Start();

You are:

• allocating memory (stack)
• asking the OS scheduler to manage it
• increasing context switching overhead

👉 This is why raw threads are rarely used in modern .NET.

2. The Thread Pool — The Real Engine

Instead of creating threads, .NET maintains a Thread Pool:

• a set of reusable worker threads
• dynamically adjusted based on load
• optimized to reduce thread creation/destruction

When you write:

Task.Run(() => DoWork());

You are not creating a thread.

👉 You are queuing work to the thread pool.

.NET decides:

• when to execute it
• on which thread
• whether to create new threads

3. Task — Not a Thread, Not Just “Async”

A Task is often misunderstood.

👉 A Task is:

“A representation of an asynchronous operation that may complete in the future.”

It is:

• not a thread
• not necessarily parallel
• a state machine + completion signal

It can represent:

• CPU work (via Task.Run)
• I/O operations (HTTP, DB, file system)
• already completed work (Task.FromResult)

4. async/await — A Compiler Transformation

This is where things get interesting.

When you write:

var data = await GetDataAsync();

The compiler transforms your method into a state machine.

Conceptually:

1. Start executing synchronously
2. Hit await
3. If not completed:

• store the current state
• return control to caller

4. When task completes:

• resume execution from that exact point

👉 No thread is “paused”
👉 The method is split into continuation pieces

5. I/O vs CPU — The Critical Distinction

I/O-bound work (most async code)

await httpClient.GetAsync(url);

👉 No thread is actively working
👉 The OS handles the operation
👉 A thread is only used:

• to start the request
• to resume when it’s done

CPU-bound work

await Task.Run(() => Compute());

👉 A thread is actively used
👉 This is real parallel execution

6. Concurrency vs Parallelism

These are often confused.

Concurrency

var t1 = GetDataAsync();
var t2 = GetDataAsync();
await Task.WhenAll(t1, t2);

👉 Multiple operations in progress
👉 May NOT use multiple threads

Parallelism

Parallel.For(0, 10, i => Compute(i));

👉 Multiple threads executing simultaneously
👉 CPU is actively used

7. Task.WhenAll — Coordination, Not Magic

var tasks = new[]
{
    GetUserAsync(),
    GetOrdersAsync(),
    GetPaymentsAsync()
};

await Task.WhenAll(tasks);

What happens:

• all tasks start immediately
• execution overlaps
• completion is awaited collectively

👉 Total time ≈ longest task
👉 Not sum of tasks

Important:

👉 WhenAll does NOT create threads
👉 It only coordinates tasks

8. Thread Starvation — The Silent Killer

This is where misunderstandings become production issues.

for (int i = 0; i < 100000; i++)
{
    Task.Run(() => DoWork());
}

You just:

• flooded the thread pool
• increased queue time
• slowed everything down

👉 More tasks ≠ more performance

9. Blocking vs Non-Blocking

Blocking

Thread.Sleep(5000);

👉 Thread is occupied doing nothing
👉 Cannot be reused

Non-blocking

await Task.Delay(5000);

👉 Thread is released
👉 Can serve other work

10. Continuations and Thread Switching

After an await, execution may resume:

• on the same thread
• on another thread from the pool

👉 You should never rely on thread identity

This is why:

• UI frameworks manage synchronization contexts
• server-side code avoids thread assumptions

You create a page.
Then another.
Then another…

And suddenly:

• Same UI appears everywhere
• Same logic is duplicated across components
• Same bugs… reproduced multiple times

At that point, you’re not building anymore.

You’re maintaining repetition.

That’s where one principle quietly changes everything:

=> DRY — Don’t Repeat Yourself

What DRY Really Means (Beyond the Definition)

DRY is not about writing less code.

It’s about writing code that doesn’t betray you later.

Because every duplicated line is:

• another place to fix bugs
• another place to forget updates
• another opportunity for inconsistency

In Blazor, this happens faster than you think.

A Classic Blazor Mistake

Let’s take something simple: loading data.

You start with this:

@if (IsLoading)
{
    <p>Loading...</p>
}
else
{
    <p>@Data</p>
}

Seems fine.

Until you repeat it in:

• Dashboard
• Profile page
• Settings
• Reports

Now you have 6 versions of the same UI.

Want to improve the design?

=> Update it 6 times.
=> Miss one? Welcome to inconsistency.

The DRY Mindset Shift

Instead of asking:

“How do I implement this?”

Ask:

“Will I need this again?”

If yes → extract it immediately

Components Are Not Optional — They’re Essential

Blazor is built for reuse.

So use it.

Instead of repeating:

<p>Loading...</p>

Create:

<LoadingIndicator />

Now:

• One change → everywhere updated
• Consistent UI
• Cleaner code

= > That’s DRY done right.

Logic Does Not Belong Everywhere

Another common pattern:

try
{
    var users = await api.GetUsers();
}
catch
{
    await Toast.ShowErrorAsync("Something went wrong");
}

You copy this into:

• Users page
• Admin panel
• Reports

Now error handling is duplicated everywhere.

Better approach:

• Centralize API calls
• Centralize error handling

=> One logic → reused everywhere

Build Small Reusable UI Blocks

You don’t need big components.

You need smart, reusable pieces.

Instead of repeating:

<div>
    <strong>Email:</strong> @user.Email
</div>

Create:

<InfoField Label="Email" Value="@user.Email" />

Now your UI becomes:

• cleaner
• consistent
• easy to maintain

Stop Repeating UI Patterns

The real problem is not copying code.

It’s copying structures.

Example patterns:

• Title + description + icon
• Label + value
• Card layout

If you see this pattern twice → extract it.

Because patterns spread faster than code.

Templates = Simple but Powerful DRY

Sometimes UI is similar… but not identical.

That’s where RenderFragment helps.

Without DRY

<div class="card">
    <h3>Users</h3>
    <p>Total: @UsersCount</p>
</div>

<div class="card">
    <h3>Orders</h3>
    <p>Total: @OrdersCount</p>
</div>

Same structure repeated.

With DRY using RenderFragment

Create a reusable container:

<!-- CardContainer.razor -->
<div class="card">
    @ChildContent
</div>

@code {
    [Parameter]
    public RenderFragment ChildContent { get; set; }
}

Use it:

<CardContainer>
    <h3>Users</h3>
    <p>Total: @UsersCount</p>
</CardContainer>

<CardContainer>
    <h3>Orders</h3>
    <p>Total: @OrdersCount</p>
</CardContainer>

=> Same layout
=> Different content
=> Zero duplication

Base Components

Sometimes multiple pages share:

• loading state
• initialization logic
• common services

You can use:

@inherits BasePage

But be careful:

=> Use it for shared behavior
=> Not for everything

Too much abstraction can make your code harder to understand.

The Trap Most Developers Fall Into

Here’s the truth:

Not all duplication is bad.

Trying to remove every duplication leads to:

• over-engineering
• unreadable abstractions
• confusion

=> DRY is about removing meaningful repetition, not everything.

A Better Way to Think

When writing code, ask yourself:

• Will I copy this somewhere else?
• Will I need to update this in multiple places?
• Is this logic reusable?

If yes → extract it.
If no → keep it simple.

The Rule That Makes You Better Instantly

If you write the same thing twice, stop and rethink.

That moment is where good developers become great ones.