Coder Legion - Recent posts tagged asp

Your Refresh Tokens Are Probably Leaking Access Right Now

Fri, 01 May 2026 22:00:15 +0000

The Refresh Token Problem Nobody Talks About

Most developers think JWT authentication is straightforward.

You issue a token. You validate it. You move on.

It works perfectly in local development. Clean. Predictable. Simple.

Until you try to build something real.

Something with real users. Real sessions. Real security expectations.

That is when refresh tokens stop being "just an implementation detail." They become the hardest part of your entire system.

And nobody warns you about this.

Where things start to break

Access tokens are easy to understand.

Short lived. Stateless. Disposable.

You can reason about them quickly. They come in, they do their job, they expire. Done.

But refresh tokens are different.

They introduce state into a system that was supposed to be stateless. And suddenly you are asking questions that most tutorials never answer:

Where do you store refresh tokens safely?
Do you allow multiple active sessions per user?
How do you rotate tokens without breaking users mid-session?
What happens when a token is stolen?
How do you actually revoke access?

At this point, the system stops being "just JWT auth." It becomes a session management problem.

And that is a completely different beast.

The real production issue

The real challenge is not issuing tokens.

It is controlling identity over time.

Because once a refresh token exists, you have essentially created a long lived key to your system. A key that can outlive passwords. That can survive logouts if you are not careful. That can be stolen and used for days or weeks.

Now you need to answer something uncomfortable:

How do I take access away after I have already given it?

Most implementations do not really solve this. They either:

Ignore revocation completely
Rely on short expirations and hope the user experience survives
Build custom logic that becomes fragile over time

None of these scale cleanly in real systems.

The failure patterns show up later

You do not notice the problem immediately.

It shows up slowly.

A user logs out but still has access somewhere. A stolen token keeps working until expiry. Multiple devices behave inconsistently. Session state becomes impossible to reason about.

And the worst part?

Everything still looks correct in code. The auth middleware passes. The refresh endpoint returns a 200. Your logs show nothing obviously wrong.

But your system is leaking access.

I have seen this happen on production systems with thousands of users. The team did everything by the book. And still, refresh tokens became the weak link.

Why most tutorials fail you

Tutorials show you how to issue a refresh token. They rarely show you how to manage it.

They will give you a nice endpoint that returns a refresh token and an access token. Maybe they store the refresh token in a database. And then… they stop.

They do not tell you:

How to handle token reuse on the same device
How to detect a stolen token when the attacker and real user both try to refresh
What to do when two concurrent requests try to rotate the same token
How to clean up expired tokens without leaking user data

You learn these things the hard way. Usually after an incident. Usually during a long night of debugging.

What actually matters in production

Once you hit production, refresh tokens stop being about authentication.

They become about control.

Here is what actually matters:

Rotation strategies

Do you issue a new refresh token on every refresh? Or keep the same one? Each approach has trade offs. Rotation is safer but harder to get right.

Reuse detection

If a refresh token is used twice, someone probably stole it. Your system needs to detect this and revoke everything immediately.

Revocation logic

Can you remotely kill a refresh token? Can you revoke all tokens for a user? Can you revoke a specific device? These are not optional in serious systems.

Storage safety

HttpOnly cookies vs mobile storage vs web workers. Each has different risk profiles. Most people get this wrong because the browser fights you at every step.

Session tracking

How do you know what devices are active? How do you show users their sessions? How do you let them remotely log out of an old phone they lost?

Most developers only learn this after rebuilding the system more than once.

The hidden cost of doing it yourself

I have built JWT auth from scratch four times.

Every time, I thought "this time will be different." Every time, refresh tokens humbled me.

The hidden cost is not the initial implementation. It is the ongoing maintenance. The edge cases you missed. The subtle bugs that only show up under load or with specific race conditions.

One team I worked with had a refresh token bug for eight months. Eight months. They thought logout was working. It was not. Tokens kept refreshing silently in the background. Users showed up as "active" weeks after leaving the platform.

That is the kind of problem that erodes trust in your system.

What I ended up doing

After going through this a few times, I stopped treating it like a one off implementation.

I sat down and asked: what would a production ready refresh token system actually need to include?

Proper rotation with reuse detection
Revocation that actually works
Multiple session support with device tracking
Clean handling of concurrent refresh requests
Secure storage guidance for different client types
Role based access control layered on top

Not a tutorial version. A production shaped one.

I packaged it into a clean, reusable setup for .NET APIs. It handles the hard parts so you do not have to debug race conditions at 2 AM.

If you are building anything with real users and real sessions, it might save you the rebuild I went through.

You can find it here:
https://yaman95.gumroad.com/l/advanced-plug-and-play-dot-net-api-security-kit

Final thought

JWT auth is not the hard part.

The hard part is everything around it. The part that decides whether your system stays secure after it goes live. The part that most tutorials skip because it is not flashy.

Refresh tokens are not a feature you add at the end. They are a design decision that shapes everything from your database schema to your logout flow to your incident response plan.

Don't learn this the hard way like I did.

Start with the hard questions early. And if you want a head start, you know where to look.

# The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

Tue, 07 Apr 2026 10:01:22 +0000

The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

Business rules rarely stay in one place.

A small validation starts in a command handler. Another check appears in a service. A third gets added somewhere in the domain. A few weeks later, the real business policy is scattered across the application, and nobody can see it clearly anymore.

That is exactly where the Rule pattern becomes useful.

At its core, the idea is simple. Instead of expressing business decisions as anonymous conditionals spread throughout the system, you give each rule a name and wrap it in its own object. Martin Fowler describes this style through the Specification pattern, where the statement of what satisfies a candidate is separated from the candidate itself, and those specifications can be combined into richer logic. (martinfowler.com)

In practical C# applications, especially the ones using CQRS or domain-driven design, that gives you something powerful: business rules that are explicit, reusable, and easy to reason about. (martinfowler.com)

What the Rule pattern really solves

The biggest problem is not that business checks exist. The problem is that they often exist in the wrong shape.

When rules are buried inside handlers, services, or controller actions, they are hard to spot, hard to test in isolation, and very easy to duplicate. The code still works, but the business language disappears.

The Rule pattern fixes that by turning each business condition into a named concept. Instead of asking developers to interpret a chain of low-level checks, the code starts speaking in terms the business would actually recognize. That is very much in line with DDD’s emphasis on modeling around the real language of the domain. (Microsoft Learn)

In other words, the pattern is not just about validation. It is about clarity.

Why it is often called the Specification pattern

If the shape feels familiar, that is because it usually is. What many teams call a Rule pattern is very close to what Fowler documented as Specification. The core idea is to represent business criteria as composable objects rather than raw conditionals, and then combine them with logical operations like AND, OR, and NOT. (martinfowler.com)

That is why this pattern tends to feel so natural in real systems. Business rules are rarely isolated. More often, they are layered:

A customer must be verified.
An order must reach a minimum amount.
A credit limit must not be exceeded.

On their own, each rule is simple. The real value appears when they can be combined into a meaningful policy.

Why this pattern becomes more valuable as the system grows

At first, a few inline checks seem harmless. But as the application grows, the cost of hidden business logic grows with it.

Rules get copied into multiple workflows.
One endpoint enforces them, another forgets.
A handler applies three checks, a background job applies only two.
Tests start focusing on branches instead of policies.

When rules become standalone concepts, those problems start to shrink. You can test a rule directly. You can reuse it in multiple flows. You can combine it with other rules. Most importantly, you can read the application flow and understand what it is trying to protect.

That is one of the reasons this pattern fits so well in systems that care about maintainability.

Where the Result pattern fits

The Rule pattern answers one question:

Is this action allowed according to the business?

The Result pattern answers another:

What happened when we tried to perform it?

That separation is the reason the two patterns fit together so well.

The rule evaluates business truth.
The result communicates application outcome.

Vladimir Khorikov’s writing on Result-based error handling makes this distinction especially useful for expected failures. Instead of throwing exceptions for normal business rejections, you can return an explicit failure outcome and keep the flow predictable. (Enterprise Craftsmanship)

That gives you a very clean mental model:

The domain decides.
The application reports.

Why this pairing feels so clean in practice

A good rule object should not care about HTTP, API responses, logging, UI wording, or transport concerns. Its responsibility is much smaller. It answers whether a business condition holds.

The application layer then takes that answer and decides what to do next. If the rule fails, the application can return a failure result. If it passes, the use case continues.

This separation lines up well with Microsoft’s DDD guidance, which treats validations as invariants and emphasizes that aggregates are responsible for enforcing consistency across state changes. (Microsoft Learn)

That is why the combination works so well. The rule keeps business logic clean. The result keeps flow control clean.

A simple order example, without the code

Imagine an order placement use case with three policies:

The order must meet a minimum amount.
The customer must be verified.
The order must stay within the customer’s credit limit.

Without a rule-based approach, those checks often end up inline inside the command handler. That works, but the handler slowly becomes the place where business policy lives.

With a rule-based approach, those policies become named rules. The handler simply coordinates the workflow: load data, build the order, evaluate the rule set, return a success or failure result, and persist when everything is valid.

That is a much healthier separation of concerns.

The handler stops being the place where business logic is invented, and becomes the place where business logic is orchestrated.

The biggest benefit is not flexibility, it is readability

People often talk about this pattern in terms of reuse or composability, and those are real benefits.

But the biggest benefit is readability.

When rules are named well, the code starts reading like a business conversation instead of a technical negotiation. That matters more than people think. Clear code reduces mistakes, speeds up maintenance, and makes onboarding easier for everyone who touches the system later.

A long chain of conditionals tells you how the system behaves.

A well-named rule tells you why.

One important design note

There is one trap worth mentioning.

Just because a rule is expressed cleanly does not automatically mean it belongs in the application layer.

Some rules are just use-case checks. Those can live comfortably near the workflow.

But some rules are true invariants of the domain. Those should usually be protected by the aggregate itself. Microsoft’s guidance is very clear on this point: aggregates are responsible for enforcing invariants across state changes. (Microsoft Learn)

So the right question is not only, “Can I model this as a rule?”

The better question is, “Who is responsible for protecting this rule?”

If the answer is “the domain itself,” then the aggregate should not rely on the handler to remember it.

Where this pattern can go wrong

Like most good patterns, this one becomes dangerous when overused.

Not every if statement needs to become a rule object.
Not every workflow needs an entire rules engine.
Not every tiny validation deserves its own abstraction.

If the business logic is trivial and local, introducing rule classes may create more ceremony than value.

The pattern shines when the rules are meaningful, reusable, and important enough to deserve a name. If the condition is just a one-off technical check, a plain conditional may still be the better choice.

The goal is not abstraction for its own sake. The goal is to make business intent easier to see.

Why the Result pattern keeps the design honest

The Result pattern adds a second layer of clarity.

A failure is no longer hidden behind a thrown exception for something the system fully expected. Instead, the caller gets an explicit outcome. That makes business rejections feel normal rather than exceptional, which is often the right model for application workflows. (Enterprise Craftsmanship)

When paired with rules, the flow becomes very natural:

Evaluate the business policy.
If it fails, return a failure result.
If it passes, continue the operation.

That is simple, predictable, and easy to test.

Final thought

The Rule pattern is one of those ideas that looks modest at first, but pays off more and more as the codebase grows.

It helps you name business policies.
It helps you reuse them.
It helps you combine them.
And when paired with the Result pattern, it gives your application a very clean way to both enforce rules and communicate outcomes. (martinfowler.com)

If your handlers are starting to fill up with business conditionals, this pattern is often a strong sign that the code wants a better language.

And that, more than anything else, is what good domain design is really about.

Source code :

https://github.com/stevsharp/RulePatternApplication

References

Martin Fowler, Specifications. (martinfowler.com)

Microsoft Learn, Designing validations in the domain model layer. (Microsoft Learn)

Microsoft Learn, Designing a DDD-oriented microservice. (Microsoft Learn)

Vladimir Khorikov, Error handling: Exception or Result? (Enterprise Craftsmanship)

Vladimir Khorikov, Advanced error handling techniques. (Enterprise Craftsmanship)

ASP.NET Core Custom Logger — Save Logs to Database (SQL)

Fri, 30 Jan 2026 09:30:43 +0000

ASP.NET Core already gives you solid logging out of the box, and if you want richer sinks and structured logs, Serilog is a common choice.

But sometimes you cannot use a ready made sink, because the company already has a legacy logging table with a fixed schema. In that case, you build a custom database logger that writes into that table.

This tutorial includes:

Database table
Logger options
Custom logger
Logger provider
Background queue (Channel)
Dapper SQL insert
Registration in Program.cs
Usage example

1️⃣ Create the SQL table

CREATE TABLE dbo.AppLogs
(
    LogId     BIGINT IDENTITY PRIMARY KEY,
    Ts        DATETIME2(3) NOT NULL,
    Level     NVARCHAR(20) NOT NULL,
    Category  NVARCHAR(200) NOT NULL,
    TraceId   NVARCHAR(64) NULL,
    Message   NVARCHAR(MAX) NOT NULL,
    Exception NVARCHAR(MAX) NULL,
    Scopes    NVARCHAR(MAX) NULL
);

CREATE INDEX IX_AppLogs_Ts    ON dbo.AppLogs(Ts);
CREATE INDEX IX_AppLogs_Level ON dbo.AppLogs(Level);

2️⃣ Add NuGet packages

dotnet add package Dapper
dotnet add package Microsoft.Data.SqlClient

3️⃣ Logger options

public sealed class DbLogOptions
{
    public string ConnectionString { get; set; } = string.Empty;
    public LogLevel MinLevel { get; set; } = LogLevel.Information;

    // Max number of log entries waiting in memory
    public int MaxQueue { get; set; } = 5000;
}

4️⃣ Log entry model

public sealed class DbLogEntry
{
    public DateTime Ts { get; set; }
    public string Level { get; set; } = "";
    public string Category { get; set; } = "";
    public string? TraceId { get; set; }
    public string Message { get; set; } = "";
    public string? Exception { get; set; }
    public string? Scopes { get; set; }
}

5️⃣ Custom database logger

using System.Diagnostics;
using System.Text.Json;
using System.Threading.Channels;
using Microsoft.Extensions.Logging;

public sealed class DbLogger : ILogger
{
    private readonly string _category;
    private readonly DbLogOptions _options;
    private readonly Channel<DbLogEntry> _channel;
    private readonly IExternalScopeProvider? _scopeProvider;

    public DbLogger(
        string category,
        DbLogOptions options,
        Channel<DbLogEntry> channel,
        IExternalScopeProvider? scopeProvider)
    {
        _category = category;
        _options = options;
        _channel = channel;
        _scopeProvider = scopeProvider;
    }

    public IDisposable BeginScope<TState>(TState state) =>
        _scopeProvider?.Push(state) ?? NullScope.Instance;

    public bool IsEnabled(LogLevel logLevel) => logLevel >= _options.MinLevel;

    public void Log<TState>(
        LogLevel logLevel,
        EventId eventId,
        TState state,
        Exception? exception,
        Func<TState, Exception?, string> formatter)
    {
        if (!IsEnabled(logLevel)) return;
        if (formatter is null) return;

        var traceId = Activity.Current?.TraceId.ToString();

        string? scopesJson = null;
        if (_scopeProvider is not null)
        {
            var scopes = new List<object?>();
            _scopeProvider.ForEachScope((s, list) => list.Add(s), scopes);

            if (scopes.Count > 0)
                scopesJson = JsonSerializer.Serialize(scopes);
        }

        var entry = new DbLogEntry
        {
            Ts = DateTime.UtcNow,
            Level = logLevel.ToString(),
            Category = _category,
            TraceId = traceId,
            Message = formatter(state, exception),
            Exception = exception?.ToString(),
            Scopes = scopesJson
        };

        // If queue is full, this returns false and the log is dropped
        _ = _channel.Writer.TryWrite(entry);
    }

    private sealed class NullScope : IDisposable
    {
        public static readonly NullScope Instance = new();
        public void Dispose() { }
    }
}

6️⃣ Logger provider (writes to SQL using Dapper)

This provider uses a bounded channel and a single background reader so request threads never block on SQL.

using System.Threading.Channels;
using Dapper;
using Microsoft.Data.SqlClient;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

public sealed class DbLoggerProvider : ILoggerProvider, ISupportExternalScope
{
    private readonly DbLogOptions _options;
    private readonly Channel<DbLogEntry> _channel;
    private readonly CancellationTokenSource _cts = new();
    private IExternalScopeProvider? _scopeProvider;

    public DbLoggerProvider(IOptions<DbLogOptions> options)
    {
        _options = options.Value;

        var channelOptions = new BoundedChannelOptions(_options.MaxQueue)
        {
            SingleReader = true,
            SingleWriter = false,
            FullMode = BoundedChannelFullMode.DropOldest
        };

        _channel = Channel.CreateBounded<DbLogEntry>(channelOptions);

        _ = Task.Run(ProcessQueueAsync);
    }

    public ILogger CreateLogger(string categoryName) =>
        new DbLogger(categoryName, _options, _channel, _scopeProvider);

    public void SetScopeProvider(IExternalScopeProvider scopeProvider) =>
        _scopeProvider = scopeProvider;

    public void Dispose()
    {
        _cts.Cancel();
        _channel.Writer.TryComplete();
        _cts.Dispose();
    }

    private async Task ProcessQueueAsync()
    {
        const string sql = @"
INSERT INTO dbo.AppLogs (Ts, Level, Category, TraceId, Message, Exception, Scopes)
VALUES (@Ts, @Level, @Category, @TraceId, @Message, @Exception, @Scopes);";

        try
        {
            while (await _channel.Reader.WaitToReadAsync(_cts.Token))
            {
                while (_channel.Reader.TryRead(out var entry))
                {
                    await using var conn = new SqlConnection(_options.ConnectionString);
                    await conn.ExecuteAsync(sql, entry);
                }
            }
        }
        catch (OperationCanceledException)
        {
            // graceful shutdown
        }
    }
}

7️⃣ Add registration extension

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

public static class DbLoggerExtensions
{
    public static ILoggingBuilder AddDbLogger(
        this ILoggingBuilder builder,
        Action<DbLogOptions> configure)
    {
        builder.Services.Configure(configure);
        builder.Services.AddSingleton<ILoggerProvider, DbLoggerProvider>();
        return builder;
    }
}

8️⃣ Register in Program.cs

var builder = WebApplication.CreateBuilder(args);

builder.Logging.ClearProviders();
builder.Logging.AddConsole();

builder.Logging.AddDbLogger(options =>
{
    options.ConnectionString = builder.Configuration.GetConnectionString("DefaultConnection")!;
    options.MinLevel = LogLevel.Information;
    options.MaxQueue = 5000;
});

var app = builder.Build();

app.MapGet("/test", (ILogger<Program> logger) =>
{
    logger.LogInformation("Hello from DB Logger");
    logger.LogError(new Exception("Test"), "Something failed");
    return Results.Ok("OK");
});

app.Run();

Why we used Channels in the DB logger

Your logger needs to accept logs from many producers (web requests, background jobs, services) and write them to the DB via one efficient writer without blocking request threads or losing control when traffic spikes. Channels are a great fit:

Non blocking producers
Backpressure with bounded capacity
Single reader, many writers
Async, allocation friendly
Graceful shutdown

Source code:
https://github.com/stevsharp/DbLoggerSample

Carter in a CQRS API, advantages and alternatives.

Wed, 07 Jan 2026 11:35:52 +0000

Carter in a CQRS API, advantages and alternatives.

In this project I wanted the API layer to stay small and structured. I like minimal APIs, but I don’t like having 200 endpoints inside Program.cs. That’s why I used Carter, it keeps the minimal API style and gives you a module system to organize endpoints by feature.

Repo used in this article:

https://github.com/stevsharp/ChainOfResponsibilityWithMediatR

Advantages of Carter

1) Feature-based organization without controllers

Carter pushes you to group endpoints in modules, for example PurchaseOrdersModule. This fits well with CQRS because you already think in features (Create, Approve, Reject, Get, List).

2) Minimal API feeling, but more maintainable

You still write endpoints in a minimal way (no heavy controller attributes), but you don’t end up with a giant Program.cs. Microsoft itself suggests structuring and organizing minimal APIs once they grow, Carter just gives a ready approach for it.

3) Cleaner API layer when using MediatR

When you combine Carter + MediatR, the endpoint usually becomes:

map route
bind request
call Send
return result

So your API layer stays thin and does not become “business logic + validation + database code”.

4) Testing and readability

Modules are easy to scan. If you want to see all Purchase Orders endpoints, you open one file. That’s a small thing, but in real teams it saves time.

5) Works nicely with Swagger and standard middleware

Carter is still based on ASP.NET Core endpoints, so you can keep standard middleware, and Swagger still works (with the normal setup).

Alternatives

Alternative 1, Controllers

Controllers (heavier):

Good when:

you want strong conventions and attributes everywhere
you already have a big MVC style codebase
your team prefers the familiar controller structure

Less good when:

you want very thin endpoints and feature modules
you end up with “controller bloat” and many attributes

Alternative 2, Pure Minimal APIs (no Carter)

Minimal APIs are great, and they are official. If your API is small, this is the simplest approach.

Good when:

small service with few endpoints
you want the simplest possible setup

Less good when:

endpoints grow and you need structure
Program.cs becomes huge

Microsoft has guidance on organizing minimal APIs because this is a real pain point once the API gets bigger.

Alternative 3, FastEndpoints (another popular option)

FastEndpoints is another library with a very feature oriented style, it also keeps endpoints separated and organized.

Good when:

you want a strong endpoint-per-class structure
you like conventions for validation, mapping, and request/response patterns

Less good when:

you want the thinnest layer possible over native ASP.NET Core endpoints

Alternative 4, Minimal APIs with Endpoint Groups (manual modules)

You can also do your own “module system” without extra libraries:

extension methods like app.MapPurchaseOrderEndpoints()
group routes with MapGroup("/api/purchase-orders")

This is a valid approach and stays 100% framework-only.

Good when:

you want no external dependency
you like simple grouping patterns

Less good when:

you still need to enforce structure across a team
endpoint definitions become scattered if not disciplined

Why I still chose Carter here

For this project size, Carter gave me the best balance:

minimal code style
good organization
no heavy framework feeling

And with CQRS + MediatR, it keeps the flow very clean: endpoint → mediator → handler.

References

How I Built a CQRS Approval Flow with MediatR, Carter, FluentValidation, and SQLite

Tue, 30 Dec 2025 10:40:18 +0000

The tech stack I used and why (updated, with Repository and Unit of Work)

This project is small, but I wanted it to feel like a real API you can extend. The repository is here:

https://github.com/stevsharp/ChainOfResponsibilityWithMediatR

Carter for endpoints

I used Carter because I like minimal APIs, but I still want structure. Carter lets you group endpoints by feature (modules) without big controllers, so the API layer stays clean. (Microsoft Learn)

CQRS with MediatR

CQRS is the separation of:

Commands (write, change state)
Queries (read, return data)

With MediatR, the endpoint just does mediator.Send(...) and the logic lives in a handler. This keeps endpoints thin and makes features easy to follow.

ICommand and IQuery marker interfaces

I added ICommand and IQuery as simple marker interfaces on top of MediatR requests. This is not a “framework”, it is only a clean way to tag what is a write and what is a read.

The reason is pipeline behaviors. With these markers, I can run transactions only for commands, and avoid wrapping queries.

MediatR pipeline behaviors

Pipeline behaviors are like middleware around every handler (IPipelineBehavior<TRequest, TResponse>). (

In this project I use:

LoggingBehavior, so I see execution time and request names
ValidationBehavior, so invalid requests never reach business logic
TransactionBehavior, so commands run inside a transaction

This keeps handlers focused, no repeated boilerplate.

FluentValidation

I used FluentValidation because it keeps validation clean and testable. It also supports assembly scanning registration, so validators are discovered automatically.

Repository pattern (why it exists here)

The Repository is used as a boundary between the application and persistence. In simple words, the application talks to an interface like IPurchaseOrderRepository, and Infrastructure decides how the data is stored (EF Core, SQLite, later maybe something else).

Conceptually, a repository “looks like” an in-memory collection for your domain objects, but it hides the database mapping details.

This is the classic definition from Fowler. (martinfowler.com)

In this project, repositories help me keep handlers free from EF Core code, so handlers read more like business use cases.

Unit of Work (and how it connects to DbContext)

A Unit of Work groups changes and commits them together. Fowler describes it as tracking everything you do in a business transaction and coordinating writing changes to the database. (martinfowler.com)

Important detail: in EF Core, DbContext is already designed to be used as a unit of work. Microsoft docs even explain that a DbContext instance is typically used for a single unit of work, then you call SaveChanges and dispose it. (Microsoft Learn)

So why still have IUnitOfWork in the Application layer?

Because it is not only about “needing” it, it is about controlling dependencies. Sometimes you want:

handlers to never call EF directly
one SaveChangesAsync per command (enforced in one place)
the possibility to swap persistence later without touching application code

So IUnitOfWork is an Application abstraction, Infrastructure implements it by calling DbContext.SaveChangesAsync. (Microsoft Learn)

EF Core + SQLite

EF Core is the persistence technology, SQLite is the lightweight database so the project runs locally with minimal setup. For a demo project, it is perfect.

Also, EF Core saving is straightforward: you change tracked entities, then call SaveChanges or SaveChangesAsync to persist. (Microsoft Learn)

Swagger (Swashbuckle)

Swagger is here so you can test endpoints fast without Postman. It gives visibility to request and response contracts, which is very useful in demos and early development.

Domain patterns, Chain of Responsibility and Specification

The business part is the approval flow. I used Chain of Responsibility to avoid one big if/else if method, and I used Specification style rules so conditions stay readable and composable. This makes it easy to add new approval levels without rewriting old logic. (Coder Legion)

References

GitHub repository:

https://github.com/stevsharp/ChainOfResponsibilityWithMediatR

Original article on CoderLegion:

https://coderlegion.com/8906/chain-of-responsibility-inside-cqrs-with-mediatr-a-small-practical-example

How to use Carter in a CQRS API, advantages and alternatives :

https://coderlegion.com/9342/carter-in-a-cqrs-api-advantages-and-alternatives

MediatR pipeline behaviors (IPipelineBehavior):
FluentValidation DI scanning:
Repository pattern (Fowler): (martinfowler.com)
Unit of Work pattern (Fowler): (martinfowler.com)
EF Core: DbContext as unit of work + SaveChanges lifecycle: (Microsoft Learn)

Building a Simple Cron Scheduler in .NET with Cronos

Fri, 28 Nov 2025 18:29:26 +0000

1. Introduction

Most .NET apps need some kind of background work. Sending emails, generating reports, cleaning data, all of these are better when they run automatically on a schedule, instead of being triggered by users.

You do not always need a heavy framework like Quartz or Hangfire. For many scenarios a lightweight cron based scheduler in a console or worker service is more than enough.

In this tutorial you will build a small but powerful console scheduler that:

Uses Cronos, a library for parsing cron expressions and calculating next run times
Runs multiple jobs with different cron expressions
Executes jobs in parallel, so a slow job does not block the rest
Handles graceful shutdown using CancellationToken

Cronos itself does not execute jobs, it only parses cron expressions and calculates occurrences, which makes it perfect as a building block for your own scheduler. (GitHub)

2. Prerequisites

You will need:

.NET 8 SDK or newer
Basic C# knowledge
NuGet package Cronos

3. Project setup

Create a new console project and add Cronos.

dotnet new console -n ConsoleCronSchedulerDemo
cd ConsoleCronSchedulerDemo

dotnet add package Cronos

Your final structure will look like this:

ConsoleCronSchedulerDemo/
 ├─ Program.cs
 ├─ Jobs/
 │   ├─ ICronJob.cs
 │   ├─ EmailJob.cs
 │   ├─ ReportJob.cs
 │   └─ Scheduler.cs
 └─ README.md  (optional)

4. Defining the cron job contract

First, create a Jobs folder and add ICronJob.cs. This interface describes what every scheduled job must provide.

// Jobs/ICronJob.cs
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleCronSchedulerDemo.Jobs;

public interface ICronJob
{
    /// <summary>
    /// Human friendly name, used in logs.
    /// </summary>
    string Name { get; }
    /// <summary>
    /// Cron expression in standard 5 field format
    /// for example "*/1 * * * *".
    /// </summary>
    string CronExpression { get; }
    /// <summary>
    /// Job logic.
    /// </summary>
    Task ExecuteAsync(CancellationToken stoppingToken);
}

Each job knows:

Its name, for logging
Its cron expression, a simple string
The work it needs to perform, exposed as ExecuteAsync

5. Implementing concrete jobs

Now create two simple demo jobs.

5.1 EmailJob

// Jobs/EmailJob.cs
using System;
using System.Threading;
using System.Threading.Tasks;

public class EmailJob(string cronExpression, IEmailService emailService) : ICronJob
{
    private readonly IEmailService _emailService = emailService;
    public string Name => "EmailJob";
    public string CronExpression { get; } = cronExpression;

    public async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        await _emailService.SendReportAsync();

        Console.WriteLine($"[{Name}] Email sent at {DateTimeOffset.Now}");
    }
}

5.2 ReportJob

// Jobs/ReportJob.cs
using System;
using System.Threading;
using System.Threading.Tasks;

public class ReportJob(string cronExpression, IReportService reportService) : ICronJob
{
    private readonly IReportService _reportService = reportService;
    public string Name => "ReportJob";
    public string CronExpression { get; } = cronExpression;

    public async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        await _reportService.GenerateReportAsync();

        Console.WriteLine($"[{Name}] Report generated at {DateTimeOffset.Now}");
    }
}

These jobs are just writing to the console, but in a real application they could send emails, generate reports, call APIs, clean a database, or whatever your business needs.

6. The scheduler that uses Cronos

Now you create a scheduler that:

Takes a list of ICronJob implementations
Uses Cronos to parse each cron expression and compute the next occurrence
Loops continuously, checking if any job is due
Runs each due job in its own Task
Respects a CancellationToken so you can shut down cleanly

Create Jobs/Scheduler.cs.

// Jobs/Scheduler.cs
public sealed class Scheduler
{
    private readonly ILogger<Scheduler> _logger;
    private readonly List<(ICronJob job, CronExpression expression)> _jobs;
    private readonly TimeZoneInfo _timeZoneInfo;
    private readonly SemaphoreSlim _semaphore;
    private readonly SchedulerSettings _settings;

    public Scheduler(
        IEnumerable<ICronJob> cronJobs,
        ILogger<Scheduler> logger,
        SchedulerSettings settings)
    {
        _logger = logger;
        _settings = settings ?? new SchedulerSettings();
        _jobs = [.. cronJobs.Select(job => (job, CronExpression.Parse(job.CronExpression)))];
        _timeZoneInfo = TimeZoneInfo.Local;

        var max = _settings.MaxConcurrentJobs > 0 ? _settings.MaxConcurrentJobs : 1;

        _semaphore = new SemaphoreSlim(max);
    }
    /// <summary>
    /// 
    /// </summary>
    /// <param name="stoppingToken"></param>
    /// <returns></returns>
    public async Task StartAsync(CancellationToken stoppingToken)
    {
        var nextRuns = _jobs.ToDictionary(
            j => j.job.Name,
            j => j.expression.GetNextOccurrence(DateTimeOffset.Now, _timeZoneInfo));

        _logger.LogInformation("Scheduler started with {JobCount} jobs, max {Max} concurrent.", _jobs.Count, _settings.MaxConcurrentJobs);

        while (!stoppingToken.IsCancellationRequested)
        {
            var now = DateTimeOffset.Now;

            foreach (var (job, expression) in _jobs)
            {
                var next = nextRuns[job.Name];

                if (!next.HasValue || next.Value > now)
                    continue;

                _logger.LogInformation("Running {Job} at {Now}", job.Name, now);

                _ = Task.Run(() => RunJobWithRetryAsync(job, stoppingToken), stoppingToken);

                nextRuns[job.Name] = expression.GetNextOccurrence(now.AddSeconds(1), _timeZoneInfo);

                _logger.LogInformation("Next run of {Job} scheduled at {Next}",job.Name, nextRuns[job.Name]);
            }

            try
            {
                await Task.Delay(1000, stoppingToken);
            }
            catch (OperationCanceledException)
            {
                _logger.LogInformation("Scheduler cancellation requested.");

                break;
            }
        }

        _logger.LogInformation("Scheduler stopped.");
    }
    /// <summary>
    /// 
    /// </summary>
    /// <param name="job"></param>
    /// <param name="ct"></param>
    /// <returns></returns>
    private async Task RunJobWithRetryAsync(ICronJob job, CancellationToken ct)
    {
        bool acquired = false;
        try
        {
            await _semaphore.WaitAsync(ct);

            acquired = true;

            var maxRetries = Math.Max(0, _settings.MaxRetries);
            var attempt = 0;

            while (!ct.IsCancellationRequested)
            {
                attempt++;

                try
                {
                    await job.ExecuteAsync(ct);

                    _logger.LogInformation("{Job} completed successfully (attempt {Attempt}).", job.Name, attempt);

                    return;
                }
                catch (OperationCanceledException) when (ct.IsCancellationRequested)
                {
                    _logger.LogInformation("{Job} cancelled during execution.", job.Name);

                    return;
                }
                catch (Exception ex)
                {
                    if (attempt > maxRetries)
                    {
                        _logger.LogError(ex, "{Job} failed after {Attempts} attempts.", job.Name, attempt - 1);
                        return;
                    }

                    var delay = GetBackoffDelay(attempt);

                    _logger.LogWarning(ex, "{Job} failed on attempt {Attempt}. Retrying in {Delay}...", job.Name, attempt, delay);

                    await Task.Delay(delay, ct);
                }
            }
        }
        catch (OperationCanceledException)
        {
            _logger.LogInformation("{Job} scheduling cancelled before start.", job.Name);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Unexpected error while scheduling/executing {Job}.", job.Name);
        }
        finally
        {
            if (acquired)
            {
                _semaphore.Release();
            }
        }
    }
    /// <summary>
    /// 
    /// </summary>
    /// <param name="attempt"></param>
    /// <returns></returns>
    private TimeSpan GetBackoffDelay(int attempt)
    {
        var baseSeconds = Math.Max(1, _settings.RetryDelaySeconds);
        // Exponential backoff: 1, 2, 4, 8, ...
        var exponent = Math.Min(attempt - 1, 10);

        var seconds = baseSeconds * (int)Math.Pow(2, exponent);

        // Add small jitter to avoid thundering herd
        var jitterMs = Random.Shared.Next(100, 500);

        var delay = TimeSpan.FromSeconds(seconds) + TimeSpan.FromMilliseconds(jitterMs);

        var maxDelay = TimeSpan.FromMinutes(2);

        return delay <= maxDelay ? delay : maxDelay;
    }
}

Why use Cronos here

Cronos gives you CronExpression.Parse(string) and GetNextOccurrence which calculates the next valid date time in a given time zone. This means:

You do not have to manually calculate future dates
Time zones and daylight saving changes are handled according to cron semantics (GitHub)

Your scheduler is now focused on one thing, deciding when to run jobs and starting tasks, and Cronos handles the calendar rules.

7. Wiring everything in Program.cs

Finally, wire everything together in Program.cs.

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

using NetCoreCronSchedulerDemo.Jobs;
using NetCoreCronSchedulerDemo.Model;
using NetCoreCronSchedulerDemo.Sevice;

class Program
{

static async Task Main(string[] args)
{
    // Build configuration
    var configuration = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .Build();

    // Setup DI
    var services = new ServiceCollection();
    services.AddLogging(config => config.AddConsole());
    services.AddSingleton<IEmailService, EmailService>();
    services.AddSingleton<IReportService, ReportService>();

    var schedulerSettings = configuration.GetSection("SchedulerSettings").Get<SchedulerSettings>() ?? throw new InvalidOperationException("SchedulerSettings section is missing in appsettings.json.");
    
    services.AddSingleton(schedulerSettings);
    
    // Load jobs from config
    var cronJobsConfig = configuration.GetSection("CronJobs").Get<List<CronJobConfig>>();

    if (cronJobsConfig == null || cronJobsConfig.Count == 0)
    {
        throw new InvalidOperationException("No cron jobs configured in appsettings.json.");
    }

    foreach (var jobConfig in cronJobsConfig)
    {
        if (jobConfig.Name == "EmailJob")
        {
            var emailService = services.BuildServiceProvider().GetService<IEmailService>() 
                ?? throw new InvalidOperationException("IEmailService is not registered in the service collection.");
            
            services.AddSingleton<ICronJob>(new EmailJob(jobConfig.CronExpression, emailService));
        }
        else if (jobConfig.Name == "ReportJob")
        {
            var reportService = services.BuildServiceProvider().GetService<IReportService>() 
                ?? throw new InvalidOperationException("IReportService is not registered in the service collection.");

            services.AddSingleton<ICronJob>(new ReportJob(jobConfig.CronExpression, reportService));
        }

    }

    services.AddSingleton<Scheduler>();

    var provider = services.BuildServiceProvider();

    var scheduler = provider.GetRequiredService<Scheduler>();

    Console.WriteLine("========================================");

    Console.WriteLine("Console Cron Scheduler (Advanced) started.");

    Console.WriteLine("========================================");

    await scheduler.StartAsync(CancellationToken.None);
}

}

Run the application.

```bash
dotnet run

You should see something similar to:

Console Cron Scheduler started.
Running ReportJob at 2025-11-28T18:00:00.0000000+02:00
Next run of ReportJob scheduled at 2025-11-28T18:01:00.0000000+02:00
Running EmailJob at 2025-11-28T18:00:00.0000000+02:00
Next run of EmailJob scheduled at 2025-11-28T20:00:00.0000000+02:00
[2025-11-28T18:00:02.0000000+02:00] ReportJob finished.
[2025-11-28T18:00:05.0000000+02:00] EmailJob finished.
...

8. Understanding the flow

To recap how everything works:

Program creates a list of ICronJob implementations
Scheduler wraps each job in a ScheduledJob that holds the CronExpression and NextRun time
The scheduler loop:
- Looks at current time
- Checks which jobs are due
- Starts each due job in a Task.Run
- Asks Cronos for the next occurrence and updates NextRun
The loop waits one second and repeats until CancellationToken is cancelled

Because each job runs on its own task, a long running email job will not block a quick report job.

10. Conclusion

With a few small classes you have built a reusable cron scheduler around the Cronos library that can run multiple jobs in parallel, respect time zones, and shut down cleanly.

Cronos gives you clean handling of cron expressions and their next occurrences, and your scheduler focuses on orchestrating job execution. This pattern can be reused in console apps, worker services, or even as part of a larger ASP.NET Core backend.

Source Code : https://github.com/stevsharp/NetCoreCronSchedulerDemo

️ From Spaghetti to Scalable: Refactoring a Legacy .NET App Architecture

Sat, 22 Nov 2025 20:34:12 +0000

Every developer eventually inherits a legacy .NET project the kind where every method talks to everything, and a single change breaks three other features.

We had one of those too. And instead of rewriting from scratch, we decided to refactor and evolve it step by step. Here’s what made the difference

Started with understanding, not rewriting.
We mapped dependencies and identified the real pain points before touching a single line of code.

Introduced layers gradually.
Added separation between API, business logic, and data layers — even if it wasn’t “perfect” at first.

Applied Dependency Injection.
Breaking hard-coded dependencies gave us flexibility and made testing possible for the first time.

Moved toward Clean Architecture.
Organized the solution around use cases and domain logic, not around technical layers.

Incremental refactoring > big bang rewrites.
We refactored feature by feature while keeping the app running — zero downtime.

Added automated tests along the way.
Unit tests became our safety net for each refactored module.

Introduced modern tools gradually.
Switched to EF Core, MediatR, and background jobs via Hangfire — one at a time.

After months of iteration, we transformed a fragile legacy system into a modular, testable, and scalable architecture — without losing business continuity.

Have you ever refactored a legacy .NET project? What approach worked best for you?

dotnet #softwarearchitecture #refactoring #cleanarchitecture #csharp #softwareengineering #backend #devleadership #legacycode

Tutorial: Building a .NET 9 Console App with Hangfire and Channels

Thu, 20 Nov 2025 07:56:42 +0000

Tutorial: Building a .NET 9 Console App with Hangfire and Channels

Overview

In this tutorial, you will build a .NET 8 console application that:

Polls data from an API, or simulates it
Uses System.Threading.Channels for producer consumer messaging
Runs background tasks using Hosted Services
Enqueues jobs in Hangfire using in memory storage

Why Use System.Threading.Channels

Traditional producer consumer patterns often rely on BlockingCollection or custom queues, which can introduce:

Thread contention
Blocking calls
Complex synchronization

System.Threading.Channels provides:

Asynchronous, non blocking communication between producers and consumers
Built in backpressure when using bounded channels
High performance with low allocation

In this app:

DataPollingService is the producer, it writes work items into the channel
ChannelConsumerService is the consumer, it reads items and enqueues Hangfire jobs

Why Hosted Services

Hosted services, BackgroundService, integrate with the .NET Generic Host. You get:

Graceful lifecycle management, start and stop
Dependency injection
Logging and configuration
Non blocking background loops

This app uses two hosted services:

DataPollingService simulates fetching data and writes work items to the channel
ChannelConsumerService reads from the channel and enqueues Hangfire jobs

What is `BackgroundService`

BackgroundService is a base class that implements IHostedService and gives you a long running ExecuteAsync loop. It plugs into the Generic Host, so you get DI, logging, and coordinated shutdown.

Use cases

Poll APIs or message brokers
Drain a queue or channel
Run internal maintenance tasks

Key points

Use ExecuteAsync(CancellationToken) as your main loop
Respect the cancellation token for fast shutdown
Prefer PeriodicTimer over Task.Delay in recurring loops

What is Hangfire

Hangfire is a background job processor for .NET. You enqueue a method call, Hangfire persists and executes it with workers. It supports fire and forget, delayed, recurring, continuations, and batches.

Why it helps here

The consumer stays lightweight, it only enqueues work
Processing is retried and observable with a dashboard
You can swap storage later for durability

Common job types

Fire and forget, BackgroundJob.Enqueue(() => DoWork())
Delayed, BackgroundJob.Schedule(() => DoWork(), TimeSpan.FromMinutes(5))
Recurring, RecurringJob.AddOrUpdate("nightly", () => DoWork(), "0 2 * * *")

Notes, in memory storage is fine for demos, not for production. Jobs should be idempotent.

What is `System.Threading.Channels`

Channels are high performance, async friendly, in process queues. You get a ChannelWriter<T> for producers and a ChannelReader<T> for consumers. Channels work with async and IAsyncEnumerable<T>, and avoid blocking threads.

Why they shine

Async reads and writes
Bounded channels provide backpressure
Options like SingleReader and SingleWriter reduce overhead when true

Fast read loop

while (await reader.WaitToReadAsync(ct))
    while (reader.TryRead(out var item))
        await HandleAsync(item, ct);

Steps to Build

1. Create the Project

dotnet new console -n CustomerSyncConsole
cd CustomerSyncConsole

2. Add NuGet Packages

dotnet add package Hangfire
dotnet add package Hangfire.MemoryStorage
dotnet add package Microsoft.Extensions.Hosting
dotnet add package Microsoft.Extensions.Logging.Console

3. Implement the Code

Below is a complete Program.cs with comments. It uses an unbounded channel for simplicity. See the optional bounded channel section that follows if you want backpressure.

using System.Threading.Channels;
using Hangfire;
using Hangfire.MemoryStorage;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace CustomerSyncConsole;

public sealed record CustomerWorkItem(int CustomerId, string PayloadId, DateTimeOffset ReceivedAt, string RawJson);

public interface ICustomerJobs
{
    Task ProcessCustomer(int customerId, string payloadId, CancellationToken ct = default);
}

public sealed class CustomerJobs(ILogger<CustomerJobs> logger) : ICustomerJobs
{
    private readonly ILogger<CustomerJobs> _logger = logger;

    public async Task ProcessCustomer(int customerId, string payloadId, CancellationToken ct = default)
    {
        _logger.LogInformation("Hangfire job started for Customer {CustomerId}, Payload {PayloadId}", customerId, payloadId);
        await Task.Delay(TimeSpan.FromSeconds(2), ct);
        _logger.LogInformation("Hangfire job completed for Customer {CustomerId}, Payload {PayloadId}", customerId, payloadId);
    }
}

public interface IStorage
{
    Task SaveAsync(string payloadId, string rawJson, CancellationToken ct);
}

public sealed class InMemoryStorage(ILogger<InMemoryStorage> logger) : IStorage
{
    private readonly ILogger<InMemoryStorage> _logger = logger;
    private readonly Dictionary<string, string> _store = new();

    public Task SaveAsync(string payloadId, string rawJson, CancellationToken ct)
    {
        _store[payloadId] = rawJson;
        _logger.LogInformation("Saved payload {PayloadId} in-memory (size={Size}).", payloadId, _store.Count);
        return Task.CompletedTask;
    }
}

public sealed class DataPollingService(
    ILogger<DataPollingService> logger,
    Channel<CustomerWorkItem> channel,
    IConfiguration config,
    IStorage storage) : BackgroundService
{
    private readonly ILogger<DataPollingService> _logger = logger;
    private readonly ChannelWriter<CustomerWorkItem> _writer = channel.Writer;
    private readonly IConfiguration _config = config;
    private readonly IStorage _storage = storage;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        var intervalSeconds = _config.GetValue("Polling:IntervalSeconds", 10);
        var timer = new PeriodicTimer(TimeSpan.FromSeconds(intervalSeconds));

        _logger.LogInformation("Polling started. Interval={Interval}s", intervalSeconds);

        try
        {
            while (await timer.WaitForNextTickAsync(stoppingToken))
            {
                var simulated = new[]
                {
                    new IncomingDto { CustomerId = 1, PayloadId = Guid.NewGuid().ToString("N") },
                    new IncomingDto { CustomerId = 2, PayloadId = Guid.NewGuid().ToString("N") },
                };

                foreach (var dto in simulated)
                {
                    var raw = System.Text.Json.JsonSerializer.Serialize(dto);
                    await _storage.SaveAsync(dto.PayloadId, raw, stoppingToken);

                    var item = new CustomerWorkItem(dto.CustomerId, dto.PayloadId, DateTimeOffset.UtcNow, raw);
                    await _writer.WriteAsync(item, stoppingToken);
                    _logger.LogInformation("Queued work item for Customer {CustomerId}, Payload {PayloadId}", dto.CustomerId, dto.PayloadId);
                }
            }
        }
        finally
        {
            _writer.TryComplete();
        }
    }

    private sealed class IncomingDto
    {
        public int CustomerId { get; set; }
        public string PayloadId { get; set; } = Guid.NewGuid().ToString("N");
    }
}

public sealed class ChannelConsumerService(
    Channel<CustomerWorkItem> channel,
    IBackgroundJobClient backgroundJobClient,
    ILogger<ChannelConsumerService> logger) : BackgroundService
{
    private readonly ChannelReader<CustomerWorkItem> _reader = channel.Reader;
    private readonly IBackgroundJobClient _backgroundJobClient = backgroundJobClient;
    private readonly ILogger<ChannelConsumerService> _logger = logger;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("Channel consumer started.");
        await foreach (var item in _reader.ReadAllAsync(stoppingToken))
        {
            if (item.CustomerId == 1)
            {
                var jobId = _backgroundJobClient.Enqueue<ICustomerJobs>(job => job.ProcessCustomer(item.CustomerId, item.PayloadId, CancellationToken.None));
                _logger.LogInformation("Enqueued Hangfire job {JobId} for Customer {CustomerId}, Payload {PayloadId}", jobId, item.CustomerId, item.PayloadId);
            }
        }
        _logger.LogInformation("Channel consumer stopping.");
    }
}

public static class Program
{
    public static async Task Main(string[] args)
    {
        using var host = Host.CreateDefaultBuilder(args)
            .ConfigureAppConfiguration(cfg =>
            {
                cfg.AddInMemoryCollection(new Dictionary<string, string?>
                {
                    ["Polling:IntervalSeconds"] = "10"
                });
            })
            .ConfigureLogging(logging =>
            {
                logging.ClearProviders();
                logging.AddSimpleConsole(o =>
                {
                    o.TimestampFormat = "HH:mm:ss ";
                    o.SingleLine = true;
                });
                logging.SetMinimumLevel(LogLevel.Information);
            })
            .ConfigureServices((ctx, services) =>
            {
                // Unbounded for simplicity in this tutorial
                services.AddSingleton(Channel.CreateUnbounded<CustomerWorkItem>());

                // Hangfire in memory
                services.AddHangfire(config => config.UseMemoryStorage());
                services.AddHangfireServer();

                services.AddSingleton<ICustomerJobs, CustomerJobs>();
                services.AddSingleton<IStorage, InMemoryStorage>();
                services.AddHostedService<DataPollingService>();
                services.AddHostedService<ChannelConsumerService>();
            })
            .Build();

        await host.RunAsync();
    }
}

Optional, switch to a bounded channel

For services that can receive spikes, prefer bounded channels to get backpressure.

services.AddSingleton(_ =>
{
    var opts = new BoundedChannelOptions(capacity: 512)
    {
        FullMode = BoundedChannelFullMode.Wait,
        SingleReader = true,   // one consumer service
        SingleWriter = true    // one producer service
    };
    return Channel.CreateBounded<CustomerWorkItem>(opts);
});

Replace the unbounded registration with the code above.

Best Practices

Pass CancellationToken to every WriteAsync and ReadAllAsync
Complete the writer during shutdown, then await reader completion
Make Hangfire jobs idempotent, retries can occur
Consider persistent Hangfire storage for real workloads, for example SQL Server or SQLite
Expose channel depth as a metric if you need visibility, current size versus capacity

Run it

dotnet run

You should see logs from both services. The producer writes items into the channel. The consumer enqueues Hangfire jobs for customer 1. The Hangfire server executes those jobs.

References

Decorate services in ASP.NET Core, step by step

Fri, 14 Nov 2025 11:21:56 +0000

Decorator pattern, in short

The decorator pattern is a structural design pattern that lets you add behavior to an object at runtime by wrapping it with another object that has the same interface. The wrapper forwards calls to the inner object, then adds extra work before or after the call. You keep the original contract, you can stack multiple decorators, and you avoid subclass explosion by preferring composition over inheritance.

Key points

Intent, attach additional responsibilities to an object dynamically
How, wrap an object that implements the same interface and forward
calls
Good for cross cutting concerns like logging, retry, caching,
metrics, authorization
Benefits, core code stays simple, behaviors are pluggable and
testable, decorators compose
Trade offs, more indirection and wiring, the order of decorators
matters

Why decorate in ASP.NET Core

Decoration lets you add cross cutting behavior around a service without touching its core code, for example retry, logging, metrics, caching. It keeps concerns separated and easy to test.

Packages

dotnet add package Scrutor
dotnet add package Polly

Core service

using System.Net.Http;
using System.Net.Http.Headers;
using System.Text.Json;

public interface IInvoicesClient
{
    Task<PagedResultDtoOfInvoice> GetInvoicesAsync(
        string filter, string orderBy, string include,
        int? pageIndex, int? pageSize, bool? transactionCurrency, bool? skipRounding,
        CancellationToken ct = default);
}

public sealed class InvoicesClient : IInvoicesClient
{
    private readonly HttpClient _http;
    private readonly string _baseUrl;
    private readonly Func<string> _getToken;
    private static readonly JsonSerializerOptions _json = new() { PropertyNameCaseInsensitive = true };

    public InvoicesClient(HttpClient http, string baseUrl, Func<string> getToken)
    {
        _http = http;
        _baseUrl = baseUrl.TrimEnd('/');
        _getToken = getToken;
    }

    public async Task<PagedResultDtoOfInvoice> GetInvoicesAsync(
        string filter, string orderBy, string include,
        int? pageIndex, int? pageSize, bool? transactionCurrency, bool? skipRounding,
        CancellationToken ct = default)
    {
        var url = BuildUrl(_baseUrl, filter, orderBy, include, pageIndex, pageSize, transactionCurrency, skipRounding);

        using var req = new HttpRequestMessage(HttpMethod.Get, url)
        {
#if NET5_0_OR_GREATER
            VersionPolicy = HttpVersionPolicy.RequestVersionOrHigher
#endif
        };

        var token = _getToken?.Invoke();
        if (!string.IsNullOrEmpty(token))
            req.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);

        using var resp = await _http.SendAsync(req, HttpCompletionOption.ResponseHeadersRead, ct).ConfigureAwait(false);
        resp.EnsureSuccessStatusCode();

        await using var stream = await resp.Content.ReadAsStreamAsync(ct).ConfigureAwait(false);
        return await JsonSerializer.DeserializeAsync<PagedResultDtoOfInvoice>(stream, _json, ct).ConfigureAwait(false)
               ?? new PagedResultDtoOfInvoice();
    }

    private static string BuildUrl(
        string baseUrl, string filter, string orderBy, string include,
        int? pageIndex, int? pageSize, bool? transactionCurrency, bool? skipRounding)
    {
        var q = System.Web.HttpUtility.ParseQueryString(string.Empty);
        if (!string.IsNullOrWhiteSpace(filter)) q["filter"] = filter;
        if (!string.IsNullOrWhiteSpace(orderBy)) q["orderBy"] = orderBy;
        if (!string.IsNullOrWhiteSpace(include)) q["include"] = include;
        if (pageIndex.HasValue) q["pageIndex"] = pageIndex.Value.ToString();
        if (pageSize.HasValue) q["pageSize"] = pageSize.Value.ToString();
        if (transactionCurrency.HasValue) q["transactionCurrency"] = transactionCurrency.Value ? "true" : "false";
        if (skipRounding.HasValue) q["skipRounding"] = skipRounding.Value ? "true" : "false";
        return $"{baseUrl}/invoices?{q}";
    }
}

Decorators

using Polly;
using System.Net.Sockets;

public sealed class RetryInvoicesClientDecorator : IInvoicesClient
{
    private readonly IInvoicesClient _inner;
    private readonly IAsyncPolicy _retry;

    public RetryInvoicesClientDecorator(IInvoicesClient inner)
    {
        _inner = inner;
        _retry = Policy
            .Handle<HttpRequestException>()
            .Or<IOException>()
            .Or<SocketException>()
            .Or<TaskCanceledException>(ex => !ex.CancellationToken.IsCancellationRequested)
            .WaitAndRetryAsync(3,
                attempt => TimeSpan.FromSeconds(Math.Pow(2, attempt)) +
                           TimeSpan.FromMilliseconds(Random.Shared.Next(0, 750)));
    }

    public Task<PagedResultDtoOfInvoice> GetInvoicesAsync(
        string filter, string orderBy, string include,
        int? pageIndex, int? pageSize, bool? transactionCurrency, bool? skipRounding,
        CancellationToken ct = default)
    =>
        _retry.ExecuteAsync(t =>
            _inner.GetInvoicesAsync(filter, orderBy, include, pageIndex, pageSize, transactionCurrency, skipRounding, t),
            ct);
}

Logging decorator

public sealed class LoggingInvoicesClientDecorator : IInvoicesClient
{
    private readonly IInvoicesClient _inner;
    private readonly ILogger<LoggingInvoicesClientDecorator> _log;

    public LoggingInvoicesClientDecorator(IInvoicesClient inner, ILogger<LoggingInvoicesClientDecorator> log)
    { _inner = inner; _log = log; }

    public async Task<PagedResultDtoOfInvoice> GetInvoicesAsync(
        string filter, string orderBy, string include,
        int? pageIndex, int? pageSize, bool? transactionCurrency, bool? skipRounding,
        CancellationToken ct = default)
    {
        var sw = System.Diagnostics.Stopwatch.StartNew();
        try
        {
            _log.LogInformation("Invoices request pageIndex={PageIndex} pageSize={PageSize}", pageIndex, pageSize);
            var res = await _inner.GetInvoicesAsync(filter, orderBy, include, pageIndex, pageSize, transactionCurrency, skipRounding, ct);
            _log.LogInformation("Invoices response count={Count} in {Elapsed} ms", res?.Data?.Count ?? 0, sw.ElapsedMilliseconds);
            return res;
        }
        catch (Exception ex)
        {
            _log.LogError(ex, "Invoices failed in {Elapsed} ms", sw.ElapsedMilliseconds);
            throw;
        }
    }
}

Registration with Scrutor

using Scrutor;
using System.Net;

builder.Services.AddHttpClient("Invoices", c =>
{
    c.Timeout = Timeout.InfiniteTimeSpan;
    c.DefaultRequestHeaders.Accept.ParseAdd("application/json");
})
.ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate,
    PooledConnectionLifetime = TimeSpan.FromMinutes(2),
    PooledConnectionIdleTimeout = TimeSpan.FromMinutes(1),
    MaxConnectionsPerServer = 8
});

builder.Services.AddTransient<IInvoicesClient>(sp =>
{
    var http = sp.GetRequiredService<IHttpClientFactory>().CreateClient("Invoices");
    var cfg = sp.GetRequiredService<IConfiguration>();
    var baseUrl = cfg["Erp:BaseUrl"] ?? "";
    var tokenProvider = sp.GetRequiredService<ITokenProvider>();
    return new InvoicesClient(http, baseUrl, () => tokenProvider.GetToken());
});

builder.Services.Decorate<IInvoicesClient, LoggingInvoicesClientDecorator>();
builder.Services.Decorate<IInvoicesClient, RetryInvoicesClientDecorator>();

Native DI without Scrutor

builder.Services.AddHttpClient("Invoices", c =>
{
    c.Timeout = Timeout.InfiniteTimeSpan;
    c.DefaultRequestHeaders.Accept.ParseAdd("application/json");
});

builder.Services.AddTransient<IInvoicesClient>(sp =>
{
    var http = sp.GetRequiredService<IHttpClientFactory>().CreateClient("Invoices");
    var cfg = sp.GetRequiredService<IConfiguration>();
    var baseUrl = cfg["Erp:BaseUrl"] ?? "";
    var tokenProvider = sp.GetRequiredService<ITokenProvider>();

    IInvoicesClient svc = new InvoicesClient(http, baseUrl, () => tokenProvider.GetToken());
    svc = new LoggingInvoicesClientDecorator(svc, sp.GetRequiredService<ILogger<LoggingInvoicesClientDecorator>>());
    svc = new RetryInvoicesClientDecorator(svc);
    return svc;
});

DelegatingHandler for transport concerns

Use handlers for wire level logic, keep decorators for service level logic.

public sealed class LoggingHandler : DelegatingHandler
{
    private readonly ILogger<LoggingHandler> _log;
    public LoggingHandler(ILogger<LoggingHandler> log) => _log = log;

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken ct)
    {
        var sw = System.Diagnostics.Stopwatch.StartNew();
        var response = await base.SendAsync(request, ct);
        _log.LogInformation("{Method} {Uri} -> {Status} in {Elapsed} ms",
            request.Method, request.RequestUri, (int)response.StatusCode, sw.ElapsedMilliseconds);
        return response;
    }
}

builder.Services.AddTransient<LoggingHandler>();
builder.Services.AddHttpClient("Invoices", c => { /* defaults above */ })
    .AddHttpMessageHandler<LoggingHandler>();

Best practices checklist

One retry layer only.
Per call timeout with CancelAfter.
ResponseHeadersRead for large payloads.
Small page size for large ranges.
Keep HttpClient immutable after registration.
Put auth headers on the request message.

References

Polly, official docs and GitHub.
Scrutor, GitHub and NuGet.
Microsoft docs, HttpClientFactory with resilience patterns.
Source Code

Global Exception Handler vs Custom Middleware in ASP.NET Core

Tue, 04 Nov 2025 09:38:14 +0000

The problem we’re solving

Stuff goes wrong: timeouts, not-found resources, validation fails. You want one consistent error response and clean logs, without sprinkling try/catch everywhere.

Two good options

Option A — Global Exception Handler (recommended default)

Think of it as the framework’s built-in safety net. You plug in one handler and ASP.NET Core turns exceptions into ProblemDetails JSON automatically.

Why people like it

Minimal code, fewer edge cases.
Plays nice with content negotiation.
One central place to map exception → HTTP status.

Use when: you want standard errors and consistency across the app.

Option B — Custom Exception Middleware

Your own IMiddleware that wraps the pipeline in try/catch and writes whatever JSON shape you want.

Why people use it

-Full control over the response body and headers.

-Easy to keep a legacy “envelope” format.

-Use when: clients require a specific, non-ProblemDetails format or you need special side effects.

Decision guide

-Standard JSON errors and less boilerplate → Global handler

-Legacy/bespoke response body → Middleware

-Want a single place to map exceptions to statuses → Global handler

-Heavy custom logic on errors (headers, counters) → Middleware

-Using MediatR and want clean handlers → Use a MediatR behavior to log, then rethrow so the global handler shapes the response

1) Global handler wiring (Program.cs)

builder.Services.AddExceptionHandler<GlobalExceptionHandler>();

app.UseExceptionHandler(); // put this early in the pipeline

The handler itself (GlobalExceptionHandler.cs)

using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;

public sealed class GlobalExceptionHandler : IExceptionHandler
{
    private readonly ILogger<GlobalExceptionHandler> _logger;
    private readonly IProblemDetailsService _pds;
    private readonly IHostEnvironment _env;

    public GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger, IProblemDetailsService pds, IHostEnvironment env)
        => (_logger, _pds, _env) = (logger, pds, env);

    public async ValueTask<bool> TryHandleAsync(HttpContext http, Exception ex, CancellationToken ct)
    {
        var (status, title) = ex switch
        {
            ValidationException => (422, "Validation failed"),
            NotFoundException   => (404, "Not found"),
            UnauthorizedAccessException => (401, "Unauthorized"),
            TimeoutException    => (503, "Service unavailable"),
            Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException => (409, "Concurrency conflict"),
            TaskCanceledException => (408, "Request timeout"),
            OperationCanceledException => (StatusCodes.Status499ClientClosedRequest, "Client closed request"),
            HttpRequestException => (502, "Bad gateway"),
            _ => (500, "Unexpected error")
        };

        if (status is 503 or 408) http.Response.Headers.TryAdd("Retry-After", "5");

        http.Response.StatusCode = status;

        var pd = new ProblemDetails
        {
            Status = status,
            Title = title,
            Detail = _env.IsDevelopment() ? ex.Message : null,
            Instance = http.Request.Path
        };
        if (ex is ValidationException ve) pd.Extensions["errors"] = ve.Errors;

        _logger.LogError(ex, "Unhandled exception -> HTTP {Status}", status);

        return await _pds.TryWriteAsync(new ProblemDetailsContext
        {
            HttpContext = http,
            ProblemDetails = pd,
            Exception = ex
        });
    }
}

Custom middleware skeleton

public sealed class ExceptionEnvelopeMiddleware : IMiddleware
{
    private readonly ILogger<ExceptionEnvelopeMiddleware> _logger;
    private readonly IHostEnvironment _env;
    public ExceptionEnvelopeMiddleware(ILogger<ExceptionEnvelopeMiddleware> logger, IHostEnvironment env)
        => (_logger, _env) = (logger, env);

    public async Task InvokeAsync(HttpContext ctx, RequestDelegate next)
    {
        try { await next(ctx); }
        catch (Exception ex)
        {
            if (ctx.Response.HasStarted) throw;
            _logger.LogError(ex, "Unhandled exception");

            ctx.Response.Clear();
            ctx.Response.StatusCode = ex switch
            {
                ValidationException => StatusCodes.Status422UnprocessableEntity,
                NotFoundException   => StatusCodes.Status404NotFound,
                TimeoutException    => StatusCodes.Status503ServiceUnavailable,
                _ => StatusCodes.Status500InternalServerError
            };
            ctx.Response.ContentType = "application/json";

            var body = new
            {
                title = ctx.Response.StatusCode == 422 ? "Validation failed" :
                        ctx.Response.StatusCode == 404 ? "Not found" :
                        ctx.Response.StatusCode == 503 ? "Service unavailable" : "Unexpected error",
                status = ctx.Response.StatusCode,
                traceId = ctx.TraceIdentifier,
                detail = _env.IsDevelopment() ? ex.Message : null,
                errors = ex is ValidationException ve ? ve.Errors : null
            };
            await ctx.Response.WriteAsJsonAsync(body);
        }
    }
}

Using MediatR? Add a behavior

using MediatR;

public sealed class UnhandledExceptionBehavior<TRequest,TResponse> : IPipelineBehavior<TRequest,TResponse>
    where TRequest : notnull
{
    private readonly ILogger<UnhandledExceptionBehavior<TRequest,TResponse>> _logger;
    public UnhandledExceptionBehavior(ILogger<UnhandledExceptionBehavior<TRequest,TResponse>> logger) => _logger = logger;

    public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next, CancellationToken ct)
    {
        try { return await next(); }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Unhandled exception in MediatR for {Request}", typeof(TRequest).Name);
            throw; // let the global handler shape ProblemDetails
        }
    }
}

Common pitfalls (and easy wins)

-Place the handler early. Put UseExceptionHandler() before routing and authorization.

-Don’t leak stack traces in production. Keep Detail empty unless in Development.

-Streaming/gRPC: once the response starts, you can’t switch to JSON. Log and stop.

-Map the big ones: validation → 422, not found → 404, timeouts → 503, concurrency → 409.

Takeaway

If you just want clean, predictable errors, use the global handler and be done. If your clients expect a specific JSON envelope, use a custom middleware. With MediatR, add a behavior to keep handlers tidy and let the handler (or middleware) do the final shaping.

How to Bind a MudSelect from an External Source in Blazor Using MudBlazor

Thu, 10 Apr 2025 09:15:42 +0000

Blazor is a modern framework from Microsoft that allows you to build interactive web applications using C# and .NET, both on the server and the client, without needing JavaScript. It brings the full power of .NET to the browser via WebAssembly or server-side rendering.

MudBlazor is a popular UI component library built specifically for Blazor. It offers clean, responsive components following Google's Material Design system, making it incredibly easy to create modern, beautiful, and interactive web UIs entirely in C#.

Use Case

Let’s say you need to:

Display a multi-select dropdown

Load the options from an external service

Sync selected values with the parent component

Reuse this logic throughout your application

We'll walk through a real-world pattern using MudSelect, bound to a list of brands (dtoBrands) provided by a service.

Prerequisites

A Blazor project with MudBlazor installed

A service that returns the brand data
A DTO like:

public class BrandDto
{
    public string Text { get; set; }
    public string Value { get; set; }
}

Sample Service Interface

public interface IBrandService
{
    Task<IEnumerable<BrandDto>> GetBrandsAsync();
}

The MudSelect Markup

<MudSelect T="BrandDto"
           Label="@Label"
           MultiSelection="true"
           Clearable="true"
           @bind-SelectedValues="InternalSelectedValues"
           ToStringFunc="item => item.Text">
    @if (dtoBrands.Any())
    {
        @foreach (var item in dtoBrands)
        {
            <MudSelectItem T="BrandDto" Value="item">
                @item.Text
            </MudSelectItem>
        }
    }
</MudSelect>

⚙️ Component Logic

@inject IBrandService BrandService

@code {
    [Parameter]
    public string Label { get; set; } = "Select Brands";

    [Parameter]
    public IEnumerable<BrandDto> SelectedValues { get; set; } = new HashSet<BrandDto>();

    [Parameter]
    public EventCallback<IEnumerable<BrandDto>> SelectedValuesChanged { get; set; }

    protected IEnumerable<BrandDto> dtoBrands = new List<BrandDto>();

    private IEnumerable<BrandDto> _internalSelectedValues = new HashSet<BrandDto>();

    private IEnumerable<BrandDto> InternalSelectedValues
    {
        get => _internalSelectedValues;
        set
        {
            if (_internalSelectedValues != value)
            {
                _internalSelectedValues = value;
                SelectedValuesChanged.InvokeAsync(_internalSelectedValues);
            }
        }
    }

    protected override async Task OnInitializedAsync()
    {
        dtoBrands = await BrandService.GetBrandsAsync();

        _internalSelectedValues = new HashSet<BrandDto>(
            dtoBrands.Where(x => SelectedValues.Any(s => s.Value == x.Value))
        );
    }

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        await base.SetParametersAsync(parameters);

        _internalSelectedValues = new HashSet<BrandDto>(
            dtoBrands.Where(x => SelectedValues.Any(s => s.Value == x.Value))
        );
    }
}

How It Works

♻️ Example Usage

Imagine turning this into a reusable component, like BrandSelector.razor. You’d use it like this:

<BrandSelector Label="Choose Brands"
               SelectedValues="@selectedBrands"
               SelectedValuesChanged="@OnSelectedBrandsChanged" />

Why This Pattern Rocks

By combining Blazor's powerful component model with MudBlazor's modern UI toolkit, you get:

✅ Fully data-driven dropdowns

✅ Type-safe C# components

✅ No need for JavaScript

✅ A consistent look and feel

And all of it is maintainable and testable across large-scale apps.

✅ Final Thoughts

Blazor and MudBlazor are a dream combo for building modern web apps in C#. By binding a MudSelect to an external service, you're creating a highly flexible and reusable pattern that fits beautifully in a clean architecture.

Useful Links

Blazor documentation

MudBlazor official site

MudSelect documentation

Optimistic vs. Pessimistic Concurrency in EF Core (with Table Hints)

Mon, 31 Mar 2025 10:01:25 +0000

Many experienced developers are familiar with database transactions but often overlook the key differences between optimistic and pessimistic concurrency control in Entity Framework Core (EF Core).

Understanding both approaches and how EF Core handles concurrency tokens is essential for building scalable and safe data operations, especially in systems with high transaction rates.

Concurrency control determines how multiple users or processes interact with the same data simultaneously. While optimistic concurrency is the default in EF Core, pessimistic concurrency is often misunderstood, misused, or completely ignored even by seniors engineers.

You can find the full code example at:
https://github.com/stevsharp/EfCoreExamples/tree/Efcore-Concurrency

What Is a Concurrency Token?

A concurrency token is a property that EF Core watches to detect whether a row has been modified since it was loaded. It's typically used in optimistic concurrency scenarios.

EF Core uses this token during SaveChangesAsync() to generate a WHERE clause that checks if the value is unchanged , if it has changed, a DbUpdateConcurrencyException is thrown.

How to Mark a Property as a Concurrency Token

✅ Using [ConcurrencyCheck] Attribute:

public class Product
{
    public int Id { get; set; }

    [ConcurrencyCheck]
    public int Stock { get; set; }
}

✅ Using [Timestamp] (for SQL Server rowversion column):

[Timestamp]
public byte[] RowVersion { get; set; }

✅ Fluent Configuration:

modelBuilder.Entity<Product>()
    .Property(p => p.Stock)
    .IsConcurrencyToken();

You can use any column as a concurrency token — even logical fields like LastModified, but (aka ) is the most reliable for SQL Server.

Optimistic Concurrency Control

Optimistic concurrency assumes conflicts are rare, so it doesn’t lock any data during updates. Instead, it tracks changes using concurrency tokens and throws an exception if a conflict is detected during SaveChangesAsync().

✅ When to Use

Read-heavy apps with occasional writes (e.g., blog, e-commerce frontend)

Systems where retries are acceptable

How to Implement in EF Core with a Concurrency Token

Entity:

public class Product
{
    public int Id { get; set; }
    public int Stock { get; set; }

    [Timestamp] // This is the concurrency token
    public byte[] RowVersion { get; set; }
}

Save and Handle Concurrency:

var product = await context.Products.FindAsync(1);

if (product.Stock > 0)
{
    product.Stock -= 1;

    try
    {
        await context.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException ex)
    {
        var databaseValues = await ex.Entries.Single().GetDatabaseValuesAsync();
        ex.Entries.Single().OriginalValues.SetValues(databaseValues);
    }
}

Pessimistic Concurrency Control

Pessimistic concurrency prevents conflicts altogether by locking the rows being read or modified. This ensures no one else can change the data until the transaction is complete.

❗ Important: EF Core does not support table hints like `` in LINQ. These must be applied using raw SQL.

Example: Locking Bank Account Row

using (var context = new AppDbContext())
{
    using var transaction = await context.Database.BeginTransactionAsync();

    var account = await context.Accounts
        .FromSqlRaw("SELECT * FROM Accounts WITH (UPDLOCK, ROWLOCK) WHERE Id = {0}", 1)
        .AsTracking() // Ensures the entity is tracked for updates
        .FirstOrDefaultAsync();

    if (account != null)
    {
        account.Balance -= 100;

        await context.SaveChangesAsync();
    }

    await transaction.CommitAsync();

}

Why SaveChangesAsync() Alone Is Not Always Enough

When using FromSqlRaw(), EF Core may not track the entity correctly for updates unless explicitly instructed.

Using .AsTracking() ensures EF will detect changes.

Without it, you would need to manually mark the entity as modified:

context.Entry(account).State = EntityState.Modified;

✅ Final Thoughts

Concurrency tokens (like RowVersion) play a central role in optimistic concurrency, enabling EF Core to detect conflicts without using locks.

Optimistic concurrency is ideal for most applications where data collisions are rare and performance is key.

Pessimistic concurrency is essential in financial or high-risk systems, where consistency outweighs performance.

EF Core does not support table hints like ` in LINQ, but you can **leverage them via **`, with .AsTracking() to ensure updates are recognized.

Many developers — even experienced ones — underestimate how concurrency should be managed in EF Core. The wrong approach can result in subtle bugs, lost data, or race conditions in production.

References & Further Reading

Microsoft Docs – Handling Concurrency Conflicts in EF Core

Microsoft Docs – Concurrency Tokens

Dev.to – Understanding and Using Table Hints in SQL Server

Microsoft Docs – Raw SQL Queries in EF Core

SQL Server – Table Hints in Transact-SQL

EF Core Bulk Updates and Deletes: Performance vs Change Tracking

Mon, 24 Mar 2025 20:25:26 +0000

Entity Framework Core 7 introduced two powerful methods for bulk operations:

ExecuteUpdateAsync and ExecuteDeleteAsync.

These methods are designed for high-performance scenarios where you need to update or delete multiple records efficiently without loading them into memory. They work great, but there's one caveat: EF Core's Change Tracker is not aware of these changes.

In this article, we explore how these methods work, why they bypass the Change Tracker, and most importantly—how you can audit or track changes manually when using them.

If you're not familiar with EF Core's Change Tracker, check out this introductory guide on Change Tracking to understand how EF Core monitors entity states.

Why Use ExecuteUpdateAsync and ExecuteDeleteAsync?

These methods:

Generate direct SQL UPDATE and DELETE statements.
Do not load entities into memory, improving performance.
Bypass change tracking, which avoids unnecessary overhead.

Example Usage:

// Bulk update
await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .ExecuteUpdateAsync(setters => setters.SetProperty(u => u.IsInactive, true));

// Bulk delete
await context.Users
    .Where(u => u.IsInactive)
    .ExecuteDeleteAsync();

The Problem: No Change Tracking

Because EF Core does not load entities into memory during these operations, the Change Tracker never sees them. This means:

No automatic change detection.
No SaveChangesAsync() involvement.
No triggers for audit or domain events.

So, how do you track what was changed or deleted?

1.Auditing Options for Bulk Operations

Manual Pre-Query Before Execution

Fetch affected entities before performing the batch operation.

var affectedUsers = await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .Select(u => new { u.Id, u.Name, OldValue = u.IsInactive })
    .ToListAsync();

await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .ExecuteUpdateAsync(setters => setters.SetProperty(u => u.IsInactive, true));

// Log changes manually
foreach (var user in affectedUsers)
{
    Console.WriteLine($"User {user.Name} updated: IsInactive {user.OldValue} → true");
}

Pros:

Precise control over what you log.

Access to old values.

Cons:

Requires an extra query.

May impact performance for large datasets.

Audit Table Logging

Save the affected data into an audit table before executing the bulk operation.

Example:

await context.AuditLogs.AddRangeAsync(affectedUsers.Select(user => new AuditLog
{
    EntityName = "User",
    EntityId = user.Id,
    ChangeType = "Updated",
    ChangedAt = DateTime.UtcNow,
    Description = $"User {user.Name} was updated: IsInactive {user.OldValue} → true"
}));

await context.SaveChangesAsync();

Database Triggers

Define SQL triggers to capture changes directly in the database.

Example :

CREATE TRIGGER trg_User_Delete
ON Users
AFTER DELETE
AS
BEGIN
    INSERT INTO AuditLogs (EntityName, EntityId, ChangeType, ChangedAt, Description)
    SELECT 'User', Id, 'Deleted', GETUTCDATE(), CONCAT('User ', Name, ' was deleted') FROM deleted;
END;

Pros:

Fully automated.

Ensures auditing even if EF Core is bypassed.

Cons:

Less flexible.

Harder to manage and version control.

EF Core Interceptors (Advanced)

Capture executed SQL commands using DbCommandInterceptor.

Limitation:

You can log the SQL query but not the previous values of affected entities.

public class AuditInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, CommandEventData eventData, InterceptionResult<DbDataReader> result)
    {
        Console.WriteLine($"SQL Executed: {command.CommandText}");
        return base.ReaderExecuting(command, eventData, result);
    }
}

Registering the Interceptor :

public class ApplicationDbContext : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<AuditLog> AuditLogs { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("YourConnectionStringHere");
        optionsBuilder.AddInterceptors(new AuditInterceptor());
    }

Conclusion

EF Core's ExecuteUpdateAsync and ExecuteDeleteAsync offer incredible performance for bulk data operations but come at the cost of losing automatic change tracking.

If you need to audit or track changes, the best approach is to manually query the affected data before execution or use a dedicated audit system such as audit tables or SQL triggers.

Choose the method that balances performance and auditing needs for your application.

What do you think? Do you prefer performance with manual tracking, or do you rely on EF Core's change tracking? Let us know your approach!

You can find the full code example at: https://github.com/stevsharp/EfCoreExamples/tree/BulkUpdateAndDeletes

References

Microsoft Docs - EF Core 7: ExecuteUpdate and ExecuteDelete

Microsoft Docs - Change Tracking in EF Core

Microsoft Docs - Interceptors in EF Core

Community Discussion - EF Core GitHub Issue on Change Tracking and Bulk Operations

EF Core: Lazy Loading, Eager Loading, and Loading Data on Demand

Thu, 06 Mar 2025 16:31:00 +0000

When working with Entity Framework Core (EF Core), there are different strategies for loading related data from the database.

So, how do you load a collection or other related objects?

Here are the main options:

1️⃣ Eager Loading (Include)

Loads related data immediately with the main entity using .Include().

Example: Load an Order with its Customer

var order = context.Orders
    .Include(o => o.Customer) // Load related Customer
    .First();

Example: Load a Customer with Their Orders

var customer = context.Customers
    .Include(c => c.Orders) // Load related Orders
    .First();

✅Pros:

✔ Avoids multiple database queries (N+1 problem)

✔ Simple and easy to use

❌ Cons:

❌ Can load unnecessary data, increasing query size

❌ Slower if you load too many relationships

2️⃣ Explicit Loading (Entry().Reference() / Entry().Collection())

Loads related data on demand (manually) using .Entry().

Example: Load a Single Related Entity

var order = context.Orders.First();

// Load related Customer manually
context.Entry(order).Reference(o => o.Customer).Load();

Console.WriteLine(order.Customer.Name);

Example: Load a Collection of Related Entities

var customer = context.Customers.First();

// Load related Orders manually
context.Entry(customer).Collection(c => c.Orders).Load();

Console.WriteLine($"Orders count: {customer.Orders.Count}");

✅ Pros:

✔ More control over when data is loaded

✔ Avoids unnecessary queries

❌ Cons:

❌ Requires additional queries

❌ Must remember to load data explicitly

3️⃣ Lazy Loading (Requires Proxies)

Loads related data only when accessed.

Install :

dotnet add package Microsoft.EntityFrameworkCore.Proxies

Steps to Enable Lazy Loading

Enable in DbContext:

protected override void OnConfiguring(DbContextOptionsBuilder options)
{
    options.UseLazyLoadingProxies().UseSqlite("Data Source=mydb.db");
}

Make navigation properties virtual

public virtual Customer Customer { get; set; } = default!;
public virtual List<Order> Orders { get; set; } = new();

Example Usage :

var order = context.Orders.First();

// Lazy loaded automatically when accessed

Console.WriteLine(order.Customer.Name);

✅ Pros:

✔ Simplifies code (data is loaded automatically)

✔ Works without modifying queries

❌ Cons:

❌ Requires proxies (extra package)

❌ Can lead to multiple database hits (N+1 problem)

4️⃣ Projection (Select with Anonymous Types)

Loads only specific data instead of full entities.

Example: Load Only Needed Fields

var orders = context.Orders
    .Select(o => new 
    { 
        o.OrderNumber, 
        CustomerName = o.Customer.Name 
    })
    .ToList();

foreach (var order in orders)
{
    Console.WriteLine($"{order.OrderNumber} - {order.CustomerName}");
}

✅ Pros:

✔ Best for performance (loads only required fields)

✔ Reduces unnecessary data transfer

❌ Cons:

❌ Cannot track entities (only works for read-only queries)

Summary Table

Best Practices
Use Eager Loading (Include()) when related data is always needed.

Use Explicit Loading if you want manual control.

Use Lazy Loading only if necessary (it can cause performance issues).

Use Projection (Select) when you need only some fields.

Source Code

You can find the complete source code for this tutorial at:
GitHub Repository

Here are some useful references to learn more about EF Core :

Official Microsoft Documentation
Entity Framework Core Loading Related Data
https://learn.microsoft.com/en-us/ef/core/querying/related-data

Covers Eager Loading, Explicit Loading, and Lazy Loading with examples.
EF Core: Configuring Lazy Loading
https://learn.microsoft.com/en-us/ef/core/querying/related-data/lazy

Explains how to enable Lazy Loading with proxies.
EF Core: Using Include() for Eager Loading
https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager

Details how to use .Include() and .ThenInclude().
EF Core Performance Considerations
https://learn.microsoft.com/en-us/ef/core/performance/

Best practices for optimizing queries and avoiding performance issues like N+1 queries.

Community & Blog Articles
EF Core Lazy Loading vs. Eager Loading - Which One Should You Use?
https://www.thinktecture.com/en/entity-framework-core/lazy-loading-vs-eager-loading/

A detailed comparison of when to use each strategy.
EF Core Best Practices: Avoiding Performance Pitfalls
https://www.michalbialecki.com/2020/11/29/entity-framework-core-performance-best-practices/

Covers when to use .Include(), lazy loading, and projection.

EF Core Global Query Filters: A Complete Guide

Sun, 02 Mar 2025 09:42:51 +0000

Entity Framework Core (EF Core) Global Query Filters allow you to apply filters to queries at the model level so that they automatically apply to all queries involving a specific entity.

This is particularly useful for scenarios like soft deletes, multi-tenancy, and user-based data filtering.

What is a Global Query Filter?

A global filter is a LINQ predicate that applies automatically to all queries on a specific entity type.

This means that any time you query the database, EF Core applies the filter implicitly, reducing the need for adding Where clauses manually.

Use Cases

Soft Deletes – Automatically filter out entities where IsDeleted =
true.
Multi-Tenancy – Ensure that a tenant only accesses their own data.
User-Based Filtering – Restrict users to see only their own records.

How to Define a Global Query Filter

Global filters are defined in the OnModelCreating method inside the DbContext class using the HasQueryFilter method.

Example : Soft Delete Implementation ..

public class BaseEntity
{
    public bool IsDeleted { get; set; }
}

public class Product : BaseEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>()
            .HasQueryFilter(p => !p.IsDeleted);
    }
}

Now, every query on Products automatically filters out records where IsDeleted = true.

Querying Products

var products = context.Products.ToList(); // Implicitly applies "WHERE IsDeleted = 0"

Bypassing the Global Filter

You can explicitly disable the filter using .IgnoreQueryFilters().

var allProducts = context.Products.IgnoreQueryFilters().ToList();

Applying Filters Dynamically (Multi-Tenancy Example)

public class AppDbContext : DbContext
{
    private readonly int _tenantId;

    public AppDbContext(DbContextOptions<AppDbContext> options, ITenantProvider tenantProvider)
        : base(options)
    {
        _tenantId = tenantProvider.GetTenantId();
    }

    public DbSet<Order> Orders { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>()
            .HasQueryFilter(o => o.TenantId == _tenantId);
    }
}

Now, EF Core automatically filters records based on _tenantId.

Limitations and Considerations

Filters do not apply to raw SQL queries (FromSqlRaw).
Navigation properties respect global filters (e.g., if Order has OrderDetails, the filter applies to them too).
Ensure filters do not cause unexpected performance issues on large datasets.
You can define multiple query filters per entity.

Combining Multiple Filters

modelBuilder.Entity<Product>()
    .HasQueryFilter(p => !p.IsDeleted)
    .HasQueryFilter(p => p.Status == "Active");

This results in:

SELECT * FROM Products WHERE IsDeleted = 0 AND Status = 'Active'

Disabling All Global Filters

You can disable all filters for a specific context query using:

context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

var allOrders = context.Orders.IgnoreQueryFilters().ToList();

Conclusion
EF Core’s Global Query Filters help enforce consistent rules across queries without adding redundant Where clauses. They are a powerful feature for soft deletes, multi-tenancy, and user-based access control. However, they should be used carefully, considering potential performance impacts.

Source Code

You can find the complete source code for this tutorial at:
GitHub Repository

Here are some useful references to learn more about EF Core Global Query Filters and Soft Delete:

Official EF Core Documentation
Global Query Filters
https://learn.microsoft.com/en-us/ef/core/querying/filters

Entity Framework Core SQLite Provider
https://learn.microsoft.com/en-us/ef/core/providers/sqlite/

Managing Data with EF Core
https://learn.microsoft.com/en-us/ef/core/

Community Articles & Tutorials
EF Core: Global Query Filters for Soft Deletes
https://www.thinktecture.com/en/entity-framework-core/global-query-filters/

Implementing Soft Delete in EF Core
https://medium.com/swlh/soft-delete-in-entity-framework-core-6c6b7a9784c7

Using SQLite with EF Core in Console Applications
https://code-maze.com/using-sqlite-with-entity-framework-core/

Coder Legion - Recent posts tagged asp

Your Refresh Tokens Are Probably Leaking Access Right Now

The Refresh Token Problem Nobody Talks About

Where things start to break

The real production issue

The failure patterns show up later

Why most tutorials fail you

What actually matters in production

Rotation strategies

Reuse detection

Revocation logic

Storage safety

Session tracking

The hidden cost of doing it yourself

What I ended up doing

Final thought

# The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

What the Rule pattern really solves

Why it is often called the Specification pattern

Why this pattern becomes more valuable as the system grows

Where the Result pattern fits

Why this pairing feels so clean in practice

A simple order example, without the code

The biggest benefit is not flexibility, it is readability

One important design note

Where this pattern can go wrong

Why the Result pattern keeps the design honest

Final thought

References

ASP.NET Core Custom Logger — Save Logs to Database (SQL)

1️⃣ Create the SQL table

2️⃣ Add NuGet packages

3️⃣ Logger options

4️⃣ Log entry model

5️⃣ Custom database logger

6️⃣ Logger provider (writes to SQL using Dapper)

7️⃣ Add registration extension

8️⃣ Register in Program.cs

Why we used Channels in the DB logger

Carter in a CQRS API, advantages and alternatives.

Carter in a CQRS API, advantages and alternatives.

Advantages of Carter

1) Feature-based organization without controllers

2) Minimal API feeling, but more maintainable

3) Cleaner API layer when using MediatR

4) Testing and readability

5) Works nicely with Swagger and standard middleware

Alternatives

Alternative 1, Controllers

Alternative 2, Pure Minimal APIs (no Carter)

Alternative 3, FastEndpoints (another popular option)

Alternative 4, Minimal APIs with Endpoint Groups (manual modules)

Why I still chose Carter here

References

How I Built a CQRS Approval Flow with MediatR, Carter, FluentValidation, and SQLite

The tech stack I used and why (updated, with Repository and Unit of Work)

Carter for endpoints

CQRS with MediatR

ICommand and IQuery marker interfaces

MediatR pipeline behaviors

FluentValidation

Repository pattern (why it exists here)

Unit of Work (and how it connects to DbContext)

EF Core + SQLite

Swagger (Swashbuckle)

Domain patterns, Chain of Responsibility and Specification

References

Building a Simple Cron Scheduler in .NET with Cronos

1. Introduction

2. Prerequisites

3. Project setup

4. Defining the cron job contract

The work it needs to perform, exposed as ExecuteAsync

5. Implementing concrete jobs

5.1 EmailJob

5.2 ReportJob

6. The scheduler that uses Cronos

Why use Cronos here

7. Wiring everything in Program.cs

The work it needs to perform, exposed as `ExecuteAsync`

What is `BackgroundService`

What is `System.Threading.Channels`