.NET Tips

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.

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.

Need to execute work outside an HTTP request?

Use a background service.

Common options:

• BackgroundService
• IHostedService
• Worker Service
• Hangfire
• Quartz.NET

Background services are useful for scheduled tasks, message processing, and long-running operations.

Need to access application settings?

Use IConfiguration

Common configuration sources:

• appsettings.json
• Environment variables
• User Secrets
• Azure Key Vault
• Command-line arguments

ASP.NET Core automatically combines multiple configuration providers into a single configuration object.

Need to return a proper response when something goes wrong?

Use exception handling middleware.

Common approaches:

• UseExceptionHandler()
• Custom exception middleware
• Return appropriate HTTP status codes
• Log unexpected exceptions
• Avoid exposing internal details

Centralized exception handling helps keep API responses consistent across your application.

Common techniques:

• Remove unused code
• Use better names
• Reduce duplication
• Simplify logic
• Fix bugs

Code quality often improves after these changes.

Want to protect an API endpoint?

Add the [Authorize] attribute.

Common authorization options:

• [Authorize]
• [Authorize(Roles = "Admin")]
• [Authorize(Policy = "EmployeeOnly")]
• [AllowAnonymous] for public endpoints
• Configure authentication before using authorization

Protected endpoints require authenticated users before your action executes.

Public endpoints without [Authorize] are accessible without authentication.

How do you organize authorization in your APIs?

Consider parallel execution.

Common approaches:

• Use Task.WhenAll()
• Process independent tasks concurrently
• Increase consumer instances
• Batch operations when possible
• Remove unnecessary bottlenecks

Parallel processing allows multiple operations to run at the same time rather than waiting for each to finish.

For example:

• 10 API calls executed sequentially may take 10 seconds
• 10 API calls executed in parallel may take around 1 second

Of course, parallelism isn't free. Databases, external APIs, and infrastructure still have limits.

But if your workload is independent, parallel execution is often one of the simplest ways to increase throughput.

What was the biggest throughput improvement you've achieved?