Articles about ASP.NET Core

Your architecture diagram says:

API → Application → Domain
         ↑
   Infrastructure

Your code might have other ideas.

Someone adds:

Domain → Infrastructure

Then:

Application → API

Six months later, the diagram is still beautiful.

One way to protect important boundaries is with architecture tests.

For example, you can define rules such as:

Domain must not depend on Infrastructure

Application must not depend on API

Controllers must not access repositories directly

Then run those rules as part of your test suite and CI pipeline.

Architecture tests are useful for enforcing things such as:

• Layer dependencies
• Namespace boundaries
• Module isolation
• Naming conventions
• Dependency restrictions
• Clean Architecture rules

They don't prove that your architecture is good.

They prove that specific structural rules you decided were important are still being followed.

Documentation describes the intended architecture.

Tests can check whether the code agrees.

If an architecture rule matters enough to put on the diagram, it might matter enough to test.

Using a message broker?

Assume a message might arrive more than once.

One common approach is to make the consumer idempotent.

For example:

if (await processedMessages.ExistsAsync(message.Id))
{
    return;
}

await ProcessMessageAsync(message);

await processedMessages.AddAsync(message.Id);

An idempotent handler produces the same result even when the same message is delivered repeatedly.

Common techniques include:

• Store processed message IDs
• Use unique database constraints
• Use idempotency keys
• Make updates naturally idempotent
• Execute state changes and deduplication atomically where needed

At-least-once delivery means duplicates are part of the design problem.

If the same message arrives twice, processing it twice should not create two different business outcomes.

Have values that change between environments?

Put them in the configuration.

Instead of:

var apiUrl = "https://prod-api.example.com";
var timeout = 30;

Read them from configuration:

{
  "ExternalApi": {
    "Url": "https://api.example.com",
    "TimeoutSeconds": 30
  }
}

Then bind them to options:

builder.Services.Configure<ExternalApiOptions>(
    builder.Configuration.GetSection("ExternalApi"));

Configuration works well for:

• URLs
• Timeouts
• Feature settings
• Connection strings
• Environment-specific values

Secrets should usually live in a dedicated secret store rather than source code.

If a value changes without requiring a code change, configuration is usually a better home for it.

ORM query behaving differently than expected?

Look at the generated SQL.

In EF Core, you can inspect a query with:

var query = context.Orders
    .Where(x => x.Status == OrderStatus.Completed)
    .OrderByDescending(x => x.CreatedAt);

var sql = query.ToQueryString();

Generated SQL helps you see:

• Which columns are selected
• Which joins were generated
• Where filters are applied
• How ordering works
• Whether the query matches your assumptions

LINQ is convenient, but the database still executes SQL.

When a database query is slow or surprising, looking at the database query is often useful.

Need to update many rows in EF Core?

You don't always need to load them first.

Instead of:

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

foreach (var user in users)
{
    user.Status = UserStatus.Disabled;
}

await context.SaveChangesAsync();

You can update matching rows directly:

await context.Users
    .Where(x => !x.IsActive)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(x => x.Status, UserStatus.Disabled));

ExecuteUpdateAsync() is useful when:

• You need to update many rows
• You don't need the entities in memory
• You don't need change tracking
• The update can be expressed as a database operation
• You want to avoid unnecessary round trips and allocations

The update runs directly in the database.

If you don't need the entities, loading them before updating them is optional.

Need only active customers?

Filter them in the database.

Instead of:

var customers = await context.Customers.ToListAsync();

var activeCustomers = customers
    .Where(x => x.IsActive)
    .ToList();

Prefer:

var activeCustomers = await context.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

The difference is where filtering happens.

The first approach:

• Loads every row
• Transfers every row
• Stores every row in memory
• Filters afterward

The second approach lets the database return the rows you requested.

If you need 100 customers from a table containing 1,000,000 rows, filtering before ToListAsync() tends to matter.

Client disconnected while your API is still doing expensive work?

Pass the CancellationToken.

public async Task<IActionResult> GetOrders(
    CancellationToken cancellationToken)
{
    var orders = await context.Orders
        .ToListAsync(cancellationToken);

    return Ok(orders);
}

Propagate the token through operations that support cancellation:

• Database queries
• HTTP calls
• Background operations
• Delays
• Long-running async workflows

Cancellation doesn't make every operation disappear immediately.

It signals downstream operations that the caller no longer needs the result.

If the request is gone, continuing work is often unnecessary.

Reading data that you don't plan to update?

Consider AsNoTracking().

var products = await context.Products
    .AsNoTracking()
    .Where(x => x.IsActive)
    .ToListAsync();

By default, EF Core tracks entities so it can detect changes and persist them later.

For read-only scenarios, that tracking work might not be needed.

AsNoTracking() helps by:

• Avoiding change tracking
• Reducing tracking-related memory usage
• Making the intent of the query explicit
• Working well for API reads and reporting
• Keeping read-only queries focused on reading

If you don't plan to change the entity, consider asking EF Core not to track changes.

Getting a 404 Not Found response?

Check whether the requested resource exists.

Common causes include:

• Incorrect URL
• Wrong route
• Missing endpoint
• Deleted resource
• Incorrect HTTP path
• Deployment configuration

HTTP 404 means the server did not find the requested resource.

If you're requesting /api/users but your endpoint is /api/customers, changing the URL might help.

Need to find something in a large codebase?

Use search.

Depending on your IDE, you can search for:

• File names
• Classes
• Methods
• Symbols
• Text
• References

For text on the current page, Ctrl + F is often a good starting point.

For larger searches, use your IDE's project or solution search.

Searching is usually faster than opening every file manually.