Coder Legion - Recent posts tagged core

How to Fix Core Web Vitals: LCP, CLS & INP | FloxoLab

Fri, 16 Oct 2026 15:50:00 +0000

Core Web Vitals are three numbers Google uses to measure how a page feels to a real person: how fast the main content loads, whether the layout jumps around while it does, and how quickly the page reacts when you tap or click. They are one part of page experience, which Google says its core ranking systems seek to reward. They do not override relevance or useful content.

This guide explains each of the three, plus the supporting numbers you will see in the same report, and then shows the real fixes that took this site's mobile Lighthouse performance score from 77 to 98. Nothing here is theory. It is the same work I run on client sites in an SEO audit.

What a good result looks like

In the July 2026 PageSpeed Insights test shown below, this site scored 98 on mobile and 100 on desktop using the same code. The two tests look different because mobile is run on a throttled, slower simulated device, so it always has less room to work with. Mobile is often the harder target, and it deserves priority when most of your visitors use phones. Google measures mobile and desktop field data separately, so check both instead of treating one Lighthouse score as the final answer.

Mobile: performance 98, LCP 1.9s, CLS 0, all vitals in the green.

Desktop: performance 100, LCP 0.5s, CLS 0, speed index 0.4s.

The three Core Web Vitals, one at a time

Everything on the scoreboard comes down to three real-user metrics. A page passes when 75 percent of real visitors fall inside the "good" band for each.

Metric	Measures	Good	Poor
LCP (Largest Contentful Paint)	Loading	2.5s or less	Over 4s
CLS (Cumulative Layout Shift)	Visual stability	0.1 or less	Over 0.25
INP (Interaction to Next Paint)	Responsiveness	200ms or less	Over 500ms

LCP: how fast the main thing loads

Largest Contentful Paint is the moment the biggest element in view finishes rendering, usually the hero image or the headline block. It is the reader's gut sense of "has this page loaded yet". What drags it down is nearly always one of four things: a heavy, uncompressed hero image, a slow server or host, render-blocking CSS and JavaScript that must run before anything paints, and web fonts that arrive late.

The fixes follow the causes. Compress and serve the hero as WebP at the right size, and preload it so the browser fetches it early. Use srcset so a phone pulls a small version and a desktop a larger one, instead of shipping one heavy file to every device. That is a separate lever from preloading: preload fetches the image sooner, srcset makes sure it is the right weight, and on a slow mobile connection the srcset part is often what saves the most. Cut or defer render-blocking scripts, and self-host your fonts instead of pulling them from a third-party domain. On this site LCP is 1.9s on mobile and 0.5s on desktop, and the single biggest lever was the hero image: right format, right size per device, preloaded.

CLS: whether the page holds still

Cumulative Layout Shift measures how much the content jumps around as the page loads. You have felt it: you go to tap a link, an image or banner loads above it, and the whole page shoves down. The usual culprits are images and embeds with no width and height set, ad or banner slots injected after load, and fonts that swap and reflow the text.

This is the most fixable vital, and the cheapest win on the list. Put explicit width and height (or an aspect ratio) on every image and iframe so the browser reserves the space before the file arrives. Give injected elements a fixed slot. Set font-display so a font swap does not reshuffle the layout. This site sits at a CLS of 0, and it got there almost entirely by adding size attributes to images.

INP: how fast the page answers you

Interaction to Next Paint replaced First Input Delay in March 2024. It measures the delay between you doing something, a tap, a click, a keypress, and the page actually showing a response, taking close to the worst interaction across the whole visit. A high INP is a page that feels sluggish and unresponsive, and the cause is almost always JavaScript hogging the main thread: heavy frameworks, big third-party scripts, and long tasks that block the browser from reacting. It is also the vital the most sites fail, so it is worth the attention.

The fix is to give the main thread less to do. Defer or split heavy JavaScript, hold third-party scripts off the critical path until the user needs them, and break long tasks into smaller pieces. This site now runs without client-side behavioral analytics, which removes one common source of third-party main-thread work. On sites that need analytics or other third-party scripts, keep them off the critical path and verify that delayed loading does not break consent or measurement. In the lab result shown above, total blocking time, the lab stand-in for INP, was 40 milliseconds.

The other numbers in the report

The same Lighthouse report shows three more metrics. These are lab diagnostics, useful for finding problems, but they are not the vitals Google ranks on.

First Contentful Paint (FCP). When the first text or image appears. An early signal that something is happening.
Total Blocking Time (TBT). How long the main thread was blocked during load. It is the lab proxy for INP, so lowering TBT usually lowers INP for real users too.
Speed Index. How quickly the page visibly fills in. On this site it shows 3.5s on mobile and lands in the amber band, while every actual vital is green. That is a fair reminder that the overall score is a blend, and a single amber lab number is not worth panicking over when the real-user vitals all pass.

Lab data and field data are not the same

There are two ways to measure all of this, and mixing them up causes a lot of confusion. Lab data is a single simulated test, like the Lighthouse run in the screenshots above, on a fixed device and connection. It is repeatable and great for debugging. Field data is what real Chrome users actually experienced over the last 28 days, and it is what Google uses for ranking. You can see your own field data in the Core Web Vitals report inside Search Console.

The practical order: use the lab test to find and fix problems fast, then watch the field data in Search Console to confirm real users feel the change. A lab score can be perfect while the field still lags, especially on a page that only just got fixed, because the field window is a rolling average. Reading that report is part of the wider habit covered in how to read your monthly SEO report.

When performance is only one concern on a specific URL, place this diagnosis inside an on-page audit of its indexability, search task, content, links, media, and validation. That keeps a Lighthouse number from replacing the wider page decision.

A mobile performance score also does not prove that Googlebot and customers receive complete content, usable navigation, accessible controls, or a working form. Check those separately with the mobile SEO checklist for rendering, content parity, and real phone tasks.

If the site has not launched yet, set media, script, layout-stability, and representative-template budgets in the SEO-friendly web design checklist. Performance is cheaper to protect in the design contract than to recover after every component is approved.

What actually moved this site from 77 to 98

The jump was not one clever trick. It was a short list of unglamorous fixes, each aimed at a specific metric:

Self-hosted the fonts. Pulling fonts from a third-party domain adds a connection and a render delay. Serving them from the same domain, preloaded, cut straight into LCP.
Reduced third-party JavaScript. The current site does not load client-side behavioral analytics. Removing or deferring non-essential third-party scripts reduces main-thread competition; verify consent and measurement before changing a production setup.
Responsive images in WebP. Every image ships as WebP at several sizes with srcset, so a phone downloads a small file and a desktop a larger one, never the wrong one.
Width and height on everything. Explicit dimensions on images and figures reserve their space, which is why CLS is 0.

None of that touched the design or the content. It is exactly the kind of finite, technical work that a small site needs once, not every month, which is the point I make in the technical SEO fixes agencies won't touch.

A quick checklist

Compress the hero image, serve it as WebP, and preload it.
Set width and height on every image, iframe, and embed.
Self-host fonts and set font-display so text does not reflow.
Remove unnecessary third-party scripts and defer the ones the site genuinely needs.
Test in the lab with PageSpeed Insights, then confirm in Search Console field data.

Core Web Vitals are one part of a technical SEO check, alongside indexing, schema, and titles. If you would rather have someone measure yours, find what is dragging them down, and hand you a prioritized fix list, that is exactly what the fixed-price SEO audit does: one report, a flat $150, no retainer, no ranking promises. If the work turns out to be ongoing, the monthly retainer picks it up from there. Get in touch to start.

Frequently asked questions

What are Core Web Vitals?

Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. They come from real Chrome users and feed into ranking as a page experience signal.

What is a good Core Web Vitals score?

A page passes when 75 percent of real users see LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less. In the Lighthouse lab test the overall score is good from 90 to 100. In the recorded July 2026 test, this site scored 98 on mobile and 100 on desktop.

Why is my mobile score lower than desktop?

Lighthouse tests mobile on a throttled, slower simulated device and connection, so the same page has less CPU and bandwidth to work with. Mobile is often the harder target, and it deserves priority when most of your visitors use phones. Google measures mobile and desktop field data separately, so check both instead of treating one Lighthouse score as the final answer.

Do Core Web Vitals affect SEO rankings?

Google says Core Web Vitals, together with other aspects of page experience, align with what its core ranking systems seek to reward. They are not a separate shortcut to higher rankings, and good scores do not override relevance or useful content.

Sources checked

Originally published on FloxoLab.

What Did We Lose With Abundant RAM?

Mon, 06 Jul 2026 20:15:09 +0000

Reclaiming Efficiency: A Tutorial on the Core Memory Mindset

In an era defined by terabytes of RAM, multi-core processors, and infinitely scalable cloud infrastructure, the concept of “resource scarcity” often feels like a relic of a bygone era. We build sophisticated systems atop layers of abstraction, confident that hardware will simply catch up or cloud providers will scale away any inefficiencies. But what if this abundance has led to a subtle, yet significant, loss in fundamental engineering discipline? This tutorial delves into the “core memory mindset” of early computing—a world where every byte and every clock cycle was meticulously accounted for—and explores how its principles remain profoundly relevant for today’s bloated binaries and skyrocketing cloud bills.

Introduction: The Ghosts of Mainframes Past

Imagine the 1960s: computing was physical, tangible. Magnetic core memory wasn’t a virtual concept; it was a woven grid of tiny ferrite donuts, each a literal magnetic flip representing a bit. Debugging could involve probing these physical components. This wasn’t merely a technical constraint; it fostered a unique engineering culture. Programmers weren’t just coding software; they were practically sculpting logic from raw physics. Their mental models of execution were tactile, almost mechanical, driven by an intimate, often painful, understanding of hardware limitations.

This isn’t just nostalgia. It’s a stark contrast to our current reality, where resource leaks are often just “scaled away,” and performance bottlenecks are met with “add more RAM.” The core memory mindset wasn’t about deprivation; it was about precision, foresight, and a profound respect for limited resources. By examining this approach, we can uncover valuable lessons that can inform our modern development practices, leading to more efficient, robust, and sustainable software.

Conceptual Walkthrough: Practicing the Core Memory Mindset

Applying the core memory mindset today doesn’t mean reverting to assembly language or manually threading wires. Instead, it’s a conceptual “code layout” – a way of thinking about your software’s interaction with underlying resources, regardless of the language or platform. Let’s walk through how this mindset translates into actionable principles.

Principle 1: Extreme Data Economy – Every Bit Counts

In the core memory era, data representation was a meticulous art. There was no luxury for HashMap<String, Object> for simple configurations or redundant data structures.

Modern Tendency: Storing boolean flags as bool (often occupying a full byte or word), using large objects for simple values, or relying on String keys for small lookup tables.

Core Memory Approach: Bit packing. If you have several boolean flags, pack them into a single byte. Use fixed-size integers (uint8, int16) where appropriate. Pre-calculate and store lookup tables instead of runtime computation. Represent complex states with carefully crafted bitmasks.

// Conceptual Pseudocode: Modern vs. Core Memory Data Representation

// Modern (potentially inefficient)
class UserPreferences {
    bool sendEmailNotifications;
    bool enableDarkMode;
    int  themeId; // Often int takes 4 bytes
    // ... many other individual fields
}

// Core Memory Mindset (efficient packing)
// Assume 8 bits per byte
byte userPreferencesFlags; // A single byte for many flags
const byte FLAG_SEND_EMAIL     = 0x01; // 00000001
const byte FLAG_DARK_MODE      = 0x02; // 00000010
const byte THEME_ID_MASK       = 0x0C; // 00001100 (2 bits for 4 themes)
const byte THEME_ID_SHIFT      = 2;

// To set/check:
userPreferencesFlags |= FLAG_SEND_EMAIL; // Set email flag
if (userPreferencesFlags & FLAG_DARK_MODE) { /* Dark mode is on */ }
userPreferencesFlags = (userPreferencesFlags & ~THEME_ID_MASK) | (newThemeId << THEME_ID_SHIFT); // Set theme

Principle 2: Predictable and Minimal Execution Paths – Optimize the Flow

Early engineers meticulously charted control flow to minimize CPU cycles and memory access. Jumps were expensive, and memory accesses were a carefully managed resource.

Modern Tendency: Relying on complex ORM queries that generate verbose SQL, dynamic dispatch where simpler switch statements would suffice, or excessive function calls and object instantiations in tight loops.

Core Memory Approach: Linear, predictable code. Avoid unnecessary allocations within hot paths. Use array indexing over linked list traversal for better cache performance. Think about the order of operations to minimize temporary variables or redundant calculations. Choose algorithms that are known for low memory footprint and predictable execution.

// Conceptual Pseudocode: Modern vs. Core Memory Algorithm Choice

// Modern (potentially allocates new list repeatedly)
List<Item> filterItems(List<Item> allItems, Predicate<Item> condition) {
    List<Item> filtered = new ArrayList<>();
    for (Item item : allItems) {
        if (condition.test(item)) {
            filtered.add(item);
        }
    }
    return filtered;
}

// Core Memory Mindset (in-place modification or explicit buffer reuse)
// Requires pre-allocated buffer or direct array manipulation
int filterItemsInPlace(Item[] items, int count, Predicate<Item> condition, Item[] outputBuffer) {
    int writeIndex = 0;
    for (int i = 0; i < count; i++) {
        if (condition.test(items[i])) {
            outputBuffer[writeIndex++] = items[i]; // Or move to front in-place
        }
    }
    return writeIndex; // New count
}

Principle 3: Explicit Resource Management – Master Your Domain

In a world without garbage collectors or infinite virtual memory, every byte of RAM was explicitly allocated and deallocated. Resource leaks meant system crashes.

Modern Tendency: Relying on garbage collection for memory, assuming database connections will close themselves, or letting frameworks implicitly manage file handles.
Core Memory Approach: Manual allocation/deallocation (even if conceptual in higher-level languages), aggressive reuse of memory buffers, and clear ownership models for resources. Always consider the lifecycle of an object or data structure: when is it created, used, and explicitly released? Avoid creating transient objects in performance-critical loops.

The payoff of this conceptual walkthrough is a deep, almost tactile understanding of how your code behaves at a machine level. It’s about designing with the hardware in mind, even when that hardware is abstracted away.

Conclusion: A Discipline for the Modern Age

Adopting the core memory mindset isn’t about forsaking high-level languages or abandoning productive abstractions. It’s about integrating a fundamental engineering discipline back into our development process. It’s a call to periodically “zoom out” from our comfortable layers of abstraction and consider the physical implications of our code.

By asking “What would an engineer with only 64KB of RAM do?” we cultivate habits that lead to:

Smaller Binaries: Less code, less data, reduced memory footprint.
Lower Cloud Bills: Efficient resource utilization means fewer instances, less memory, and lower CPU usage.
Improved Performance: Faster execution, better cache utilization, and reduced latency.
More Resilient Systems: Fewer hidden resource leaks or unexpected memory pressure spikes.

The convenience of abundant RAM has, perhaps, allowed us to neglect a crucial aspect of engineering. By thoughtfully re-engaging with the principles born from resource scarcity, we can build more robust, efficient, and environmentally conscious software for the present and future. Sometimes, a little bit of that old “ferrite donut” thinking is exactly what our modern systems need.

🚀 EF Core Query Optimization for Beginners

Mon, 29 Jun 2026 19:47:13 +0000

When developers first start using Entity Framework Core, it's easy to write queries that work—but not all queries perform well.

The good news? A few simple practices can make your queries much faster, use less memory, and generate better SQL.

We'll use this real-world example:

var offerDtos = await db.Offers
    .AsNoTracking()
    .Where(o => o.DeliveryDate >= date &&
                o.DeliveryDate < nextDay &&
                (o.IsCompleted == null || o.IsCompleted == 0))
    .OrderBy(o => o.Id)
    .Select(o => new OfferForWarehouseDto
    {
        OfferId = o.Id,
        CustomerName = o.Customer.Name,
        DeliveryDate = o.DeliveryDate,
        OfferDate = o.OfferDate,
        Status = o.Status,
        Comments = o.Comments,
        WarehouseStatus = "Pending",
        Lines = o.OfferLines
            .Select(l => new WarehouseLineDto
            {
                OfferLineId = l.Id,
                ItemCode = l.ItemCode,
                ItemDescription = l.ItemDescription,
                Color = l.Color,
                Unit = l.Unit,
                OrderedQuantity = l.Quantity,
                CurrentStock = l.Product.Stock
            })
            .ToList()
    })
    .ToListAsync(cancellationToken);

Let's break it down step by step.

1. Use `AsNoTracking()` for Read-Only Queries ⭐

.AsNoTracking()

One of EF Core's most useful features is the Change Tracker.

Whenever you load entities, EF Core tracks them in memory so it can detect changes and generate the appropriate INSERT, UPDATE, or DELETE statements when you call SaveChanges().

For example:

var offer = await db.Offers.FirstAsync();

offer.Status = "Completed";

await db.SaveChangesAsync();

Even though you never tell EF Core that Status changed, it knows because the Change Tracker has been monitoring the entity.

This is extremely convenient when you're editing data.

However, tracking every entity comes with a cost.

For each tracked entity, EF Core stores:

The original values
The current values
The entity state (Added, Modified, Deleted, Unchanged)
Relationship information

If you're only displaying data in a grid or returning it from an API, all of this tracking is unnecessary.

That's why read-only queries should use:

.AsNoTracking()

This tells EF Core:

"I'm only reading this data. Don't track it."

Benefits

✅ Lower memory usage
✅ Faster query execution
✅ Less CPU overhead
✅ Better performance for APIs, dashboards, and reports

Learn more

Change Tracking: https://learn.microsoft.com/en-us/ef/core/change-tracking/
Tracking vs. No-Tracking Queries: https://learn.microsoft.com/en-us/ef/core/querying/tracking

2. Filter Data Before Loading It

.Where(o =>
    o.DeliveryDate >= date &&
    o.DeliveryDate < nextDay &&
    (o.IsCompleted == null || o.IsCompleted == 0))

Always filter data in the database.

Good:

db.Offers.Where(...)

Bad:

db.Offers.ToList().Where(...)

The first generates a SQL WHERE clause.

The second loads the entire table into memory before filtering.

The database is optimized for filtering large datasets, so let it do the work.

3. Project Only What You Need

Notice that we're not returning Offer entities.

Instead, we're creating DTOs.

.Select(o => new OfferForWarehouseDto
{
    OfferId = o.Id,
    CustomerName = o.Customer.Name
})

This tells EF Core exactly which columns to retrieve.

Instead of:

SELECT *

EF Core generates SQL that selects only the properties used in the DTO.

Benefits include:

Smaller SQL results
Less network traffic
Lower memory usage
Faster execution

Learn more

https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying#project-only-properties-you-need

4. Don't Use `Include()` When Projecting

Many developers write:

.Include(o => o.Customer)
.Include(o => o.OfferLines)
.ThenInclude(l => l.Product)
.Select(...)

This is unnecessary.

When projecting into a DTO, EF Core automatically generates the required SQL joins.

Simply write:

.Select(...)

The generated SQL is usually smaller, cleaner, and more efficient.

5. Sort in SQL

Sorting should happen before materializing the results.

Good:

.OrderBy(o => o.Id)
.ToListAsync();

Bad:

.ToList()
.OrderBy(o => o.Id);

SQL Server is optimized for sorting data.

Don't move that work into your application.

6. Project Child Collections

EF Core can also project related collections.

Lines = o.OfferLines
    .Select(l => new WarehouseLineDto
    {
        ItemCode = l.ItemCode,
        CurrentStock = l.Product.Stock
    })
    .ToList()

Notice that we never load the entire OfferLine or Product entities.

Only the required columns are selected.

This keeps queries efficient while still returning nested objects.

7. Use Async Queries

Always prefer:

await ToListAsync();

instead of:

ToList();

Async queries don't make the database faster, but they prevent your application thread from blocking while waiting for SQL Server.

This improves scalability in ASP.NET Core applications.

8. Create Proper Database Indexes

Even the best LINQ query can be slow if the database has no indexes.

This query filters by:

DeliveryDate
IsCompleted

A composite index can dramatically improve performance.

CREATE INDEX IX_Offers_DeliveryDate_IsCompleted
ON Offers (DeliveryDate, IsCompleted);

Remember:

EF Core generates SQL.
SQL Server executes SQL.
Indexes make SQL fast.

Final Optimized Query

var offerDtos = await db.Offers
    .AsNoTracking()
    .Where(o => o.DeliveryDate >= date &&
                o.DeliveryDate < nextDay &&
                (o.IsCompleted == null || o.IsCompleted == 0))
    .OrderBy(o => o.Id)
    .Select(o => new OfferForWarehouseDto
    {
        OfferId = o.Id,
        CustomerName = o.Customer.Name,
        DeliveryDate = o.DeliveryDate,
        OfferDate = o.OfferDate,
        Status = o.Status,
        Comments = o.Comments,
        WarehouseStatus = "Pending",
        Lines = o.OfferLines
            .Select(l => new WarehouseLineDto
            {
                OfferLineId = l.Id,
                ItemCode = l.ItemCode,
                ItemDescription = l.ItemDescription,
                Color = l.Color,
                Unit = l.Unit,
                OrderedQuantity = l.Quantity,
                CurrentStock = l.Product.Stock
            })
            .ToList()
    })
    .ToListAsync(cancellationToken);

🎯 Key Takeaways

Whenever you write an EF Core query, ask yourself:

✅ Is this a read-only query? → Use AsNoTracking().
✅ Am I letting the database filter my data?
✅ Am I selecting only the columns I need?
✅ Am I avoiding unnecessary Include() calls?
✅ Am I using async methods like ToListAsync()?
✅ Does my database have the right indexes?

Following these simple habits will help you write faster, cleaner, and more scalable EF Core applications.

Additional Resources

EF Core Performance: https://learn.microsoft.com/en-us/ef/core/performance/
Efficient Querying: https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying
Change Tracking: https://learn.microsoft.com/en-us/ef/core/change-tracking/
Tracking vs. No-Tracking Queries: https://learn.microsoft.com/en-us/ef/core/querying/tracking

5 EF Core Features Every Enterprise Developer Should Know

Fri, 05 Jun 2026 08:47:24 +0000

Entity Framework Core (EF Core) is often introduced as an ORM that simplifies data access, but its real value in enterprise applications comes from features that improve reliability, scalability, and maintainability.

As applications grow and operate in cloud environments, these capabilities become essential rather than optional.

1. Connection Resiliency and Retry Policies

Enterprise systems frequently run on cloud-hosted databases where transient network failures, failovers, and throttling can occur. EF Core provides built-in connection resiliency by automatically retrying failed database operations.

options.UseSqlServer(connectionString, sqlOptions =>
    sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(10),
        errorNumbersToAdd: null));

This helps applications recover gracefully from temporary infrastructure issues without requiring custom retry logic throughout the codebase.

2. Optimistic Concurrency Control

In multi-user systems, preventing lost updates is critical. EF Core supports optimistic concurrency through concurrency tokens such as SQL Server's rowversion.

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

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

When another user modifies the same record, EF Core detects the conflict and throws a DbUpdateConcurrencyException, allowing the application to reload, merge, or notify the user. This ensures data integrity while avoiding expensive database locks.

3. Performance Optimization with Compiled Queries

High-throughput APIs and microservices can execute the same queries thousands of times per second. EF Core offers several performance features, including compiled queries, AsNoTracking, query splitting, and batching.

private static readonly Func<AppDbContext, int, Task<Order>> GetOrder =
    EF.CompileAsyncQuery((AppDbContext ctx, int id) =>
        ctx.Orders.AsNoTracking()
                  .FirstOrDefault(o => o.Id == id));

Compiled queries eliminate repeated LINQ-to-SQL translation overhead, while AsNoTracking reduces change-tracking costs for read-only operations. These optimizations can significantly improve throughput under load.

4. Transactions and Unit of Work

Business operations often involve multiple database changes that must either succeed together or fail together. EF Core supports explicit transactions to guarantee atomicity.

await using var tx = await context.Database.BeginTransactionAsync();

try
{
    await context.SaveChangesAsync();
    await otherContext.SaveChangesAsync();
    await tx.CommitAsync();
}
catch
{
    await tx.RollbackAsync();
    throw;
}

This capability is fundamental for maintaining consistency across aggregates, repositories, and critical business workflows.

5. Global Query Filters

Global query filters allow rules to be applied automatically to every query for a given entity. They are especially valuable for multi-tenant SaaS applications and soft-delete implementations.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Customer>()
        .HasQueryFilter(c => !c.IsDeleted);

    modelBuilder.Entity<Invoice>()
        .HasQueryFilter(x => x.TenantId == _currentTenant.Id);
}

By centralizing these concerns, developers reduce duplication and eliminate the risk of accidentally exposing data across tenants or returning deleted records.

Final Thoughts

While EF Core is easy to start with, enterprise applications require more than basic CRUD operations. Features such as connection resiliency, concurrency control, performance optimization, transactions, and global query filters help teams build systems that are robust, scalable, and maintainable in production.

Mastering these five capabilities will provide a strong foundation for building enterprise-grade applications with EF Core.

When IDbContextFactory enters the chat, and what it actually fixes.

Mon, 16 Feb 2026 09:47:23 +0000

When `IDbContextFactory` enters the chat, and what it actually fixes

Most EF Core examples use a scoped DbContext. In a normal Web API request, that’s fine, the request ends, the context is disposed.

Then you build Blazor Server.

A Blazor Server circuit can stay alive for a long time, minutes or hours. If your DbContext is scoped, it can also stay alive that long. That’s when things start to break in annoying ways.

What problems show up

1) “A second operation was started on this context…”
DbContext is not thread-safe. In Blazor Server it’s easy to trigger overlapping work (clicks, timers, loading states). If two queries happen at the same time on the same context, you get this error.

2) Tracking bloat
A long-lived context keeps tracking entities. Over time:

memory grows
queries can feel slower
SaveChanges can get heavy
you hit “already being tracked” errors

3) Stale or confusing data
Because the context tracks objects, you can end up reusing old instances without realizing it, the UI feels out of sync.

What `IDbContextFactory` changes

It gives you a fresh DbContext per operation.

create context
run the query or command
dispose the context

So each click, each load, each action gets its own clean context. No shared state, no concurrency fights, no growing tracker.

When to use it

Use IDbContextFactory when you have:

Blazor Server
background jobs or hosted services
timers, polling, signalR style event flows
any parallel DB work

In simple controller-per-request apps, scoped DbContext is still perfectly fine.

The takeaway

IDbContextFactory is not a “nice to have”, it’s the safer default when your app is long-lived and event-driven. It prevents a whole category of EF Core bugs before they happen.

Source Code :

https://github.com/stevsharp/BlazorFactoryDemo

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

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

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.

Reliable Messaging in .NET: Domain Events and the Outbox Pattern with EF Core Interceptors

Mon, 13 Oct 2025 11:27:53 +0000

Introduction

Distributed systems are powerful — but they come with one big challenge: reliability.

What happens if your application updates a record in the database and then tries to publish a message to a message broker… but crashes in between?
You’ve just lost an event.

This problem is common in microservices, and it’s why the Outbox Pattern exists — a simple, elegant approach that guarantees message delivery without introducing distributed transactions or external coordinators.

In this article, we’ll implement a Domain Event + Outbox Pattern in .NET 9, using Entity Framework Core, SQLite, and an EF Core SaveChangesInterceptor.

⚙️ A Quick Look at Entity Framework Core

Entity Framework Core (EF Core) is Microsoft’s modern Object-Relational Mapper (ORM) for .NET.
It allows developers to work with a database using C# classes instead of raw SQL, automatically handling relationships, migrations, and change tracking.

When you call SaveChanges() or SaveChangesAsync(), EF Core:

Tracks your entity changes.
Generates SQL commands.
Executes them in a transaction.

This makes EF Core the perfect place to integrate the Outbox Pattern, since we can hook into its save pipeline and ensure domain events are written in the same transaction as the data itself.

What Are Interceptors?

In EF Core, interceptors are powerful hooks that allow you to intercept and extend the framework’s internal operations — such as saving, querying, or connecting to the database.

They work like middleware for EF Core:
you can observe, modify, or add logic before and after EF performs certain actions.

There are several types:

SaveChangesInterceptor
CommandInterceptor
ConnectionInterceptor
TransactionInterceptor

In this article, we’ll use SaveChangesInterceptor to detect domain events before EF saves, serialize them, and insert them into our Outbox table.

The Problem

In traditional architectures, your service might do something like this:

await _db.SaveChangesAsync();
await _bus.PublishAsync(new OrderPlacedEvent(orderId));

If your app crashes after saving but before publishing, your event never reaches other services — resulting in inconsistent state across systems.

We need a way to ensure atomicity: either both the data and the event are persisted, or neither are.

The Outbox Pattern (In a Nutshell)

The Outbox Pattern solves this by introducing a dedicated Outbox table inside your database.

When your aggregate raises a domain event, it’s captured and saved into the Outbox table within the same transaction as your entity.
A background worker (or a separate service) polls the Outbox table, publishes events, and marks them as processed.

This way, even if your app crashes, the events are safely stored and can be retried later.

The Architecture

┌──────────────────────────────┐
│         Application          │
│ ──────────────────────────── │
│  Order raises DomainEvent    │
│  → EF Interceptor writes     │
│    Outbox row                │
│  → Transaction commits       │
└──────────────┬───────────────┘
               │
               ▼
        Outbox Dispatcher
       ├─ Polls database
       ├─ Publishes messages
       └─ Marks them processed

This pattern elegantly blends Domain-Driven Design concepts with event-driven reliability.

Domain Events

Domain events capture something meaningful that happened in your domain model.
For example:

public sealed record OrderPlacedDomainEvent(Guid OrderId, decimal Total)
    : DomainEvent(DateTime.UtcNow);

And your aggregate raises them naturally:

public sealed class Order : IHasDomainEvents
{
    private readonly List<DomainEvent> _domainEvents = new();
    public Guid Id { get; private set; } = Guid.NewGuid();
    public decimal Total { get; private set; }

    public IReadOnlyCollection<DomainEvent> DomainEvents => _domainEvents;

    public Order(decimal total)
    {
        Total = total;
        AddEvent(new OrderPlacedDomainEvent(Id, Total));
    }

    private void AddEvent(DomainEvent @event) => _domainEvents.Add(@event);
    public void ClearDomainEvents() => _domainEvents.Clear();
}

⚙️ Capturing Events with an EF Core Interceptor

Instead of overriding SaveChangesAsync() directly inside AppDbContext, we can use a SaveChangesInterceptor — a clean, composable way to plug custom logic into EF’s lifecycle.


public sealed class OutboxSaveChangesInterceptor(IEventSerializer serializer) : SaveChangesInterceptor
{
    /// <summary>
    /// 
    /// </summary>
    /// <param name="eventData"></param>
    /// <param name="result"></param>
    /// <param name="cancellationToken"></param>
    /// <returns></returns>
    public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData,
        InterceptionResult<int> result,
        CancellationToken cancellationToken = default)
    {
        var context = eventData.Context;
        if (context is null) 
            return await base.SavingChangesAsync(eventData, result, cancellationToken);

        var aggregates = context.ChangeTracker
                    .Entries()
                    .Where(e => e.Entity is IHasDomainEvents hasEvents && hasEvents.DomainEvents.Count > 0)
                    .Select(e => (IHasDomainEvents)e.Entity)
                    .ToList();

        if (aggregates.Count == 0)
            return await base.SavingChangesAsync(eventData, result, cancellationToken);

        var outbox = context.Set<OutboxMessage>();

        foreach (var aggregate in aggregates)
        {
            foreach (var @event in aggregate.DomainEvents)
            {
                outbox.Add(new OutboxMessage
                {
                    OccurredOnUtc = @event.OccurredOnUtc,
                    Type = @event.GetType().AssemblyQualifiedName!,
                    Payload = serializer.Serialize(@event)
                });
            }
        }

        return await base.SavingChangesAsync(eventData, result, cancellationToken);
    }

}

Now every time you call SaveChangesAsync(), domain events are written to your OutboxMessages table automatically — in the same transaction.

The Outbox Dispatcher

Once the transaction is committed, a background worker can safely process these messages.


public sealed class OutboxDispatcher(IServiceProvider sp, 
    ILogger<OutboxDispatcher> logger) : BackgroundService
{
    private readonly IServiceProvider _sp = sp;
    private readonly ILogger<OutboxDispatcher> _logger = logger;
    private readonly TimeSpan _pollInterval = TimeSpan.FromSeconds(2);
    private const int BatchSize = 50;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation(" Outbox Dispatcher started...");

        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                using var scope = _sp.CreateScope();
                var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

                var jsonSerializer = scope.ServiceProvider.GetRequiredService<IEventSerializer>();

                var pending = await db.OutboxMessages
                    .Where(x => x.ProcessedOnUtc == null)
                    .OrderBy(x => x.Id)
                    .Take(BatchSize)
                    .ToListAsync(stoppingToken);

                foreach (var msg in pending)
                {
                    try
                    {
                        var evt = jsonSerializer.Deserialize(msg.Payload, msg.Type);
                        await SimulatedBusPublish(evt, stoppingToken);
                        msg.ProcessedOnUtc = DateTime.UtcNow;
                        msg.Error = null;
                    }
                    catch (Exception ex)
                    {
                        msg.Error = ex.Message;
                        _logger.LogError(ex, "❌ Error dispatching OutboxMessage {Id}", msg.Id);
                    }
                }

                if (pending.Count > 0)
                    await db.SaveChangesAsync(stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Outbox dispatcher loop error");
            }

            await Task.Delay(_pollInterval, stoppingToken);
        }
    }

    private Task SimulatedBusPublish(DomainEvent evt, CancellationToken ct)
        => evt switch
        {
            OrderPlacedDomainEvent e => HandleOrderPlaced(e),
            _ => Task.CompletedTask
        };

    private Task HandleOrderPlaced(OrderPlacedDomainEvent e)
    {
        Console.WriteLine($"[BUS] ✅ OrderPlaced published => OrderId={e.OrderId}, Total={e.Total}");

        return Task.CompletedTask;
    }
}

Why Use an Interceptor?

Using an interceptor instead of overriding SaveChangesAsync() has several advantages:

Approach	Pros	Cons
Override SaveChangesAsync	Simple to start	Harder to reuse across contexts
Use Interceptor	Decoupled, reusable, testable	Slightly more setup

Interceptors follow the Open/Closed Principle — your DbContext remains focused on persistence, while cross-cutting logic (like event logging, auditing, or outbox handling) is easily attachable.

Benefits of the Outbox Pattern

✅ Transactional Safety — data + events saved atomically
✅ Guaranteed Delivery — retries handled by dispatcher
✅ DDD Alignment — aggregates raise domain events naturally
✅ Resilience — works even if message broker is offline
✅ Extensibility — can integrate with RabbitMQ, Kafka, or Azure Service Bus later

References

✨ Closing Thoughts

The Domain Events + Outbox Pattern is one of the most practical ways to achieve reliable, eventually consistent event-driven systems in .NET.

By combining Entity Framework Core, SaveChangesInterceptor, and a simple background dispatcher, you can ensure every event is persisted and delivered — even in the face of failure.

Small pattern. Big reliability.

Author

Spyros Ponaris
LinkedIn
Senior Software Engineer & .NET Enthusiast

Supercharging EF Core Specifications with EF.CompileQuery

Tue, 05 Aug 2025 07:56:23 +0000

Introduction

When you’re using EF Core in production, query compilation can quietly become a performance bottleneck — especially if the same query is executed thousands of times.

Normally, EF Core parses your LINQ, generates SQL, and prepares the execution plan every time.
With EF.CompileQuery, EF Core does that work once, caching the query plan for all future executions.

The catch?

If you’re using the Specification pattern for clean, reusable queries, your repository method probably applies a spec dynamically to DbSet — which makes EF.CompileQuery less obvious to use.

In this article, we’ll solve that and show you how to bake compiled queries into your specification-driven repository.

Quick Recap: Specification Pattern

The Specification pattern encapsulates query logic into reusable, composable units.

Example spec for active customers:

public class ActiveCustomersSpec : Specification<Customer>
{
    public ActiveCustomersSpec()
    {
        Query.Where(c => c.IsActive)
             .OrderBy(c => c.Name)
             .Include(c => c.Orders);
    }
}

Your repository then applies the spec:

public async Task<IReadOnlyList<T>> ListAsync(ISpecification<T> spec)
{
    var evaluator = new SpecificationEvaluator();
    var query = evaluator.GetQuery(_db.Set<T>().AsQueryable(), spec);
    return await query.ToListAsync();
}

The Problem

EF.CompileQuery needs a strongly-typed lambda starting from your DbContext:

private static readonly Func<AppDbContext, bool, IEnumerable<Customer>> _activeCustomers =
    EF.CompileQuery((AppDbContext db, bool isActive) =>
        db.Customers.Where(c => c.IsActive == isActive));

But with the Specification pattern, you usually pass in a spec, not a lambda on DbContext.
You don’t want every caller to remember how to invoke the compiled query.
We need a way to integrate compiled queries into the repository itself.

The Solution: Encapsulate Compiled Queries in the Repository

4.1 Create the compiled query

public static class CompiledQueries
{
    public static readonly Func<AppDbContext, bool, IEnumerable<Customer>> ActiveCustomers =
        EF.CompileQuery((AppDbContext db, bool isActive) =>
            db.Customers
              .Where(c => c.IsActive == isActive)
              .OrderBy(c => c.Name)
              .Include(c => c.Orders));
}

4.2 Update the repository

public class EfRepository<T> where T : class
{
    private readonly AppDbContext _db;
    public EfRepository(AppDbContext db) => _db = db;

    public async Task<IReadOnlyList<T>> ListAsync(ISpecification<T> spec)
    {
        // Detect known spec → use compiled query
        if (typeof(T) == typeof(Customer) && spec is ActiveCustomersSpec)
        {
            var result = CompiledQueries.ActiveCustomers(_db, true).ToList();
            return (IReadOnlyList<T>)result;
        }

        // Fallback: normal spec evaluation
        var evaluator = new SpecificationEvaluator();
        var query = evaluator.GetQuery(_db.Set<T>().AsQueryable(), spec);
        return await query.ToListAsync();
    }
}

4.3 Usage stays clean

var repo = new EfRepository<Customer>(db);
var customers = await repo.ListAsync(new ActiveCustomersSpec());

The caller doesn’t know (or care) if the query was compiled
but hot-path specs now run ~3x faster.

Ready-to-Use Libraries
Instead of writing your own Specification pattern, you can use:

Ardalis.Specification

Well-maintained, feature-rich.
Supports includes, projections, ordering, pagination.

NSpecifications

DDD-focused, composable specifications.
Great for domain-driven designs.

Both integrate nicely with EF Core and can work with this
compiled-query approach.

Best Practices
Use compiled queries for hot paths — they have a cost to set up but shine when reused often.

Avoid over-compiling — not every query benefits from precompilation.

Keep specs small and focused — huge includes and joins can still dominate runtime.

Combine with async wisely — EF.CompileQuery is sync; use EF.CompileAsyncQuery for async enumeration.

Conclusion

You don’t have to choose between clean architecture (Specification pattern) and speed.
By encapsulating EF.CompileQuery inside your repository for frequently-used specs,
you can keep your calling code clean while still getting huge performance wins.

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

⚔️ The Mighty MERGE: Using SQL Merge Statements Safely with EF Core

Fri, 25 Jul 2025 12:16:46 +0000

When you’re working with bulk data operations, upserts, or syncing external sources, MERGE is one of the most powerful tools SQL Server offers. But what happens when you need to use it alongside Entity Framework Core?

In this article, we’ll cover:

✅ What MERGE is and why it matters

How to use it with EF Core (with and without transactions)

⚠️ Common pitfalls and best practices

️ Alternatives like BulkExtensions and PostgreSQL upserts

When to use MERGE — and when not to

What Is SQL MERGE?

MERGE is a T-SQL command that allows you to INSERT, UPDATE, or DELETE in a single statement based on conditions between a source and a target.

Simple Example:

MERGE INTO Products AS Target
USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
    ON Target.Id = Source.Id
WHEN MATCHED THEN
    UPDATE SET Name = Source.Name
WHEN NOT MATCHED THEN
    INSERT (Id, Name) VALUES (Source.Id, Source.Name);

✅ The power of MERGE lies in combining multiple operations in one atomic transaction — perfect for syncing external sources, staging tables, or upserting data without multiple round-trips.

Using MERGE with EF Core
EF Core does not expose MERGE as part of its LINQ API. But you can still run raw SQL safely using:

Option 1: ExecuteSqlRaw

await dbContext.Database.ExecuteSqlRawAsync(@"
MERGE INTO Products AS Target
USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
ON Target.Id = Source.Id
WHEN MATCHED THEN
    UPDATE SET Name = Source.Name
WHEN NOT MATCHED THEN
    INSERT (Id, Name) VALUES (Source.Id, Source.Name);");

Option 2: Call a Stored Procedure

CREATE PROCEDURE MergeProducts AS
BEGIN
    MERGE INTO Products ...
END

await dbContext.Database.ExecuteSqlRawAsync("EXEC MergeProducts");

Option 3: Use EF Core Bulk Libraries

Libraries like EFCore.BulkExtensions simulate efficient MERGE behavior:

await dbContext.BulkInsertOrUpdateAsync(products);

Can I Use MERGE with EF Core Transactions?

Yes — and you should if you’re performing other EF operations in the same workflow. EF Core supports shared transactions across both raw SQL and EF operations.

✅ Full Example:

using var transaction = await dbContext.Database.BeginTransactionAsync();

try
{
    // 1. Execute MERGE
    await dbContext.Database.ExecuteSqlRawAsync(@"
        MERGE INTO Products AS Target
        USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
        ON Target.Id = Source.Id
        WHEN MATCHED THEN
            UPDATE SET Name = Source.Name
        WHEN NOT MATCHED THEN
            INSERT (Id, Name) VALUES (Source.Id, Source.Name);");

    dbContext.SyncLogs.Add(new SyncLog { Table = "Products", Timestamp = DateTime.UtcNow });
    await dbContext.SaveChangesAsync();

    await transaction.CommitAsync();
}
    catch
{
    await transaction.RollbackAsync();
    throw;
}

✅ This ensures the MERGE and the SyncLogs insert are part of the same database transaction, protecting you from partial updates.

⚠️ Warnings About SQL Server MERGE

Microsoft has acknowledged multiple bugs with MERGE in SQL Server — including:

https://learn.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql?view=sql-server-ver16#remarks

Unexpected behavior with triggers

Incorrect OUTPUT clauses

Problems with concurrent updates

✅ Safer Patterns

Use UPDATE ... and INSERT WHERE NOT EXISTS if possible

Avoid complex MERGE statements with multiple joins

Always test MERGE inside a transaction in production-like data scenarios

When Should I Use MERGE?

✅ Use MERGE if:

You need to sync two tables (e.g., staging import)

You want to upsert large volumes in one atomic step

You’re doing data warehousing or ETL pipelines

❌ Avoid MERGE if:

You're only updating/inserting a few rows

You rely on entity validation logic in your app

You need maximum concurrency safety without side effects

✨ Bonus: Reusable MERGE Helper
You can build a helper that accepts any raw SQL and executes it within a transaction:

public static async Task ExecuteMergeAsync(this DbContext db, string sql)
{
    using var tx = await db.Database.BeginTransactionAsync();
    try
    {
        await db.Database.ExecuteSqlRawAsync(sql);
        await tx.CommitAsync();
    }
    catch
    {
        await tx.RollbackAsync();
        throw;
    }

}

Conclusion

SQL MERGE is a mighty tool for any developer working with bulk updates, external data, or data sync pipelines. EF Core doesn’t have built-in support but raw SQL, stored procs, and bulk extensions let you use it safely and effectively.

Wrap it in transactions, know when it shines, and watch out for its quirks and you’ll get the best of both SQL Server and EF Core worlds.

Why Records in C# Are Great (and So Nice to Work With)

Sat, 10 May 2025 20:37:38 +0000

Why Records in C# Are Great

If you’ve been working with C# lately, you’ve probably encountered records , a feature introduced in C# 9 that many developers have come to love.

They’re elegant, powerful, and remove a lot of boilerplate when modeling data.

But what actually makes them great? Here’s why records aren’t just nice , they’re game-changing.

What Are Records?

At their core, records are reference types designed for immutable data modeling. Think of them as classes optimized for holding data with extra features built in.

You can define a record in two main ways:

✅ 1. Positional Syntax (Concise and Clean)

public record Person(string FirstName, string LastName);

This one-liner gives you:

Constructor
Equals(), GetHashCode(), and ToString() overrides
init-only properties (immutable)
Deconstruction support

Ouaaa...

In order to implement all that in a regular class, you'd need to write a lot of code constructors, equality logic, ToString() overrides, and possibly even a deconstructor.
Records do it all for you, automatically and cleanly.

✅ 2. Classic Syntax (More Flexible)

public record Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

Need mutability? You can use set instead of init, but that sacrifices immutability and thread safety.

What is init?

init is a special accessor introduced in C# 9 that allows properties to be set only during initialization making them immutable afterward.

var person = new Person { FirstName = "Alice", LastName = "Green" };
// person.FirstName = "Bob"; ❌ Not allowed

✅ Cleaner than readonly fields
✅ Safer than public setters
✅ Perfect for records, DTOs, and configuration objects

Reference:
Microsoft Docs – Init-only Setters

✅ 1. Value-Based Equality — Finally Done Right

With classes, equality checks compare references. With records, it's based on content:

var a = new Person("Alice", "Smith");
var b = new Person("Alice", "Smith");

Console.WriteLine(a == b); // True ✅

Reference:
Microsoft Docs – Records

✅ 2. Immutability by Default — and Thread-Safe by Nature

Records are immutable by default, which leads to safer, more predictable code.

var p1 = new Person("John", "Doe");
var p2 = p1 with { FirstName = "Jane" }; // Creates a copy

And since their state can't be changed after creation, records are thread-safe for read operations — perfect for:

Parallel tasks
Background services
Blazor state containers
Event sourcing

Reference:
Immutability in C#

✅ 3. Concise and Readable Code
Records eliminate boilerplate. You define what matters — and the compiler handles the rest.

public record Invoice(string Id, DateTime Date, decimal Amount);

Clean. Lightweight. Clear.

✅ 4. Deconstruction and Pattern Matching

Records play perfectly with modern C# features:

var (first, last) = new Person("Ana", "Lopez");

if (p1 is { FirstName: "John" })
{
    Console.WriteLine("Hello John!");
}

Reference:

Pattern Matching in C#

✅ 5. Functional Programming Friendly

Records align with functional principles:

No side effects
Easy transformations
Clear data flow

var updatedInvoice = invoice with { Amount = invoice.Amount + 10 };

Reference:

Welcome to C# 9 – Records

✅ 6. Supports Inheritance, Structs, and More

You’re not locked into one pattern:

record struct — value-type records
readonly record struct — fully immutable
Abstract and sealed record inheritance supported

Reference:
What's New in C# 10 – Record Structs

Records and the Value Object Pattern
In Domain-Driven Design (DDD), Value Objects are small objects that:

Represent a concept (e.g., Money, Email)

Are immutable
Have no identity
Compare by value

✅ Records Are Ideal for Value Objects

public record Email(string Address)
{
    public Email
    {
        if (!Address.Contains("@"))
            throw new ArgumentException("Invalid email");
    }
}

You get a clean, reusable object with built-in validation and equality , no fuss.

public record Money(decimal Amount, string Currency);

public record Product
{
    public Guid Id { get; init; }
    public string Name { get; init; }
    public Money Price { get; init; }
}

Reference:
Martin Fowler – Value Object

When Not to Use Records

Avoid records if:

You need full mutable entities (e.g., for EF Core)
You rely on reference identity
Your inheritance hierarchy is too complex

Real-World Use Cases

✅ DTOs for APIs

✅ Immutable configs

✅ Logging and audit trails

✅ Domain Value Objects

✅ State models in Blazor, Redux, Fluxor

✅ Event-driven architecture

Final Thoughts
C# records are more than just syntactic sugar — they promote a mindset of immutability, clarity, and value-based design.

They:

Reduce bugs
Simplify data models
Improve thread safety
Save a lot of time

Whether you're building APIs, desktop apps, or microservices, records make your C# experience cleaner and smarter.

Once you go record, you'll never want to class again.

References:

Microsoft Docs – Records

Init-only Setters in C# 9

Immutability

Pattern Matching

Dev Blog – Welcome to C# 9

Martin Fowler – Value Objects

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

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 Interceptors: Supercharge Your Data Access with the Decorator Pattern

Thu, 20 Mar 2025 08:25:11 +0000

Learn how to hook into EF Core operations using interceptors, leverage the Decorator Pattern for clean cross-cutting concerns, and see real-world examples like SQL logging and auditing.

Table of Contents

A Brief History of EF Core Interceptors
What Are EF Core Interceptors?
EF Core Interceptors and the Decorator Pattern
Top Use Cases for EF Core Interceptors
Example 1: Logging SQL Queries
Example 2: Auditing SaveChanges
Final Thoughts

A Brief History of EF Core Interceptors

EF Core interceptors were first introduced in EF Core 3.0 (released in September 2019). This version marked a significant step forward in EF Core's extensibility, allowing developers to intercept low-level database operations like commands, connections, and transactions.

Since then, Microsoft has expanded interceptor capabilities in newer versions:

EF Core 5.0: Introduced SaveChanges interceptors for tracking changes at the context level.

EF Core 6.0+: Continued performance improvements and better support for asynchronous interception.

What Are EF Core Interceptors?

In Entity Framework Core (EF Core), interceptors allow developers to hook into the execution pipeline of EF Core's operations. Think of them as middleware for your database interactions. You can intercept events such as:

SQL command execution
Connection opening/closing
Transactions
SaveChanges lifecycle

This lets you inject custom logic like logging, auditing, validation, or performance metrics without modifying your application’s core logic.

EF Core Interceptors and the Decorator Pattern

EF Core interceptors are a real-world application of the Decorator Pattern, a classic design pattern where functionality is wrapped around existing behavior to extend or alter it.

The core EF operation is the base object.
Your interceptor is the decorator.
You add behavior before or after EF Core’s operation — without altering EF’s core.

This approach promotes clean code, separation of concerns, and makes your custom behavior reusable and testable.

Top Use Cases for EF Core Interceptors

– SQL Query Logging

– Track database queries for performance or debugging.

– Auditing – Automatically log user actions and timestamps.

– Soft Deletes – Intercept delete commands and convert them to updates.

– Command Modification – Change or enrich raw SQL before execution.

– Multi-Tenant Filtering – Inject filters dynamically for multi-tenant scenarios.

Example 1: Logging SQL Queries

Let’s log every SQL command executed by EF Core.

Step 1: Create a SQL Logging Interceptor

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Diagnostics;

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

Output:

SQL Executed: SELECT * FROM [Users] WHERE [IsActive] = 1

Step 2: Register the Interceptor

public class AppDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder
            .UseSqlServer("YourConnectionString")
            .AddInterceptors(new SqlLoggingInterceptor());
    }
}

Example 2: Auditing SaveChanges

Let’s implement automatic auditing of entity modifications.

Step 1: Define an Auditable Entity Base Class

public abstract class AuditableEntity
{
    public DateTime ModifiedAt { get; set; }
    public string ModifiedBy { get; set; }
}

Step 2: Implement a SaveChangesInterceptor

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly string _currentUser;

    public AuditInterceptor(string currentUser)
    {
        _currentUser = currentUser;
    }

    public override int SavingChanges(DbContextEventData eventData, int result)
    {
        var context = eventData.Context;
        if (context == null) return base.SavingChanges(eventData, result);

        var entries = context.ChangeTracker
            .Entries<AuditableEntity>()
            .Where(e => e.State == EntityState.Modified);

        foreach (var entry in entries)
        {
            entry.Entity.ModifiedAt = DateTime.UtcNow;
            entry.Entity.ModifiedBy = _currentUser;
        }

        return base.SavingChanges(eventData, result);
    }
}

Final Thoughts

EF Core interceptors are an underutilized gem in the .NET ecosystem. They let you cleanly implement cross-cutting concerns without muddying your core application code. And because they follow the Decorator Pattern, you get flexibility, maintainability, and testability.

Whether you need to log queries, audit changes, enforce soft deletes, or handle custom behavior, interceptors offer a powerful and elegant solution.

References
EF Core Documentation – Interceptors
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors

EF Core 3.0 Release Notes (Interceptors introduced)
https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/whatsnew

EF Core SaveChanges Interceptor Docs
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors#savechanges-interception

Decorator Pattern - Refactoring Guru (for pattern explanation)
https://refactoring.guru/design-patterns/decorator

EF Core GitHub Repository (for latest updates and issues)
https://github.com/dotnet/efcore

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/

When to Use AsSplitQuery() in EF.core

Wed, 26 Feb 2025 08:10:09 +0000

When working with Entity Framework Core (EF Core), queries that involve multiple Include() statements can result in a single large query with multiple joins. This can cause performance issues due to data duplication and increased memory usage.

What is AsSplitQuery()?

AsSplitQuery() tells EF Core to fetch related data using separate SQL queries instead of one large join query. This helps optimize performance for complex queries.

Step 1: Setup Your Model

Let’s create a simple e-commerce scenario with Order, Customer, and OrderItem entities.

public class Order
{
    public int Id { get; set; }
    public string OrderNumber { get; set; }
    public Customer Customer { get; set; }
    public List<OrderItem> OrderItems { get; set; } = new();
}

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class OrderItem
{
    public int Id { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
}

Step 2: Configure the Database Context

We define our DbContext to include the necessary DbSet properties.

public class AppDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<Customer> Customers { get; set; }
    public DbSet<OrderItem> OrderItems { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlite("Data Source=app.db");
    }
}

Step 3: Query Without AsSplitQuery()

Let's say we want to fetch orders with their customers and order items.

**var orders = await _context.Orders
    .Include(o => o.Customer)
    .Include(o => o.OrderItems)
    .ToListAsync();**

What Happens Here?
EF Core generates a single SQL query with multiple JOIN operations.
If there are many orders and items, this can cause performance issues due to data duplication.

Step 4: Optimize with AsSplitQuery()

Now, let's improve performance by using AsSplitQuery().

var orders = await _context.Orders
    .Include(o => o.Customer)
    .Include(o => o.OrderItems)
    .AsSplitQuery() // Fetches data using multiple queries instead of joins
    .ToListAsync();

What Happens Now?

EF Core executes multiple separate SQL queries instead of a single large join.
Less memory is used since duplicate data is avoided.
Performance is improved when dealing with large datasets.

Step 5: Understanding the SQL Queries

Without AsSplitQuery()
EF Core runs one big SQL query:

SELECT o.*, c.*, oi.*
FROM Orders o
LEFT JOIN Customers c ON o.CustomerId = c.Id
LEFT JOIN OrderItems oi ON o.Id = oi.OrderId;

This may lead to repetitive customer data for each order item.

With AsSplitQuery()
EF Core runs separate queries:

SELECT * FROM Orders;
SELECT * FROM Customers WHERE Id IN (...);
SELECT * FROM OrderItems WHERE OrderId IN (...);

This reduces duplication and improves performance.

When to Use AsSplitQuery()

✅ Use AsSplitQuery() when:

You include multiple navigation properties (Include()).
You experience performance issues with large datasets.
You want to avoid data duplication.

❌ Avoid AsSplitQuery() when:

Your queries are already small and fast.
Your database round trips increase due to multiple queries.

Conclusion

Using AsSplitQuery() in EF Core can boost performance and reduce memory usage when working with complex queries. It’s a simple yet powerful optimization that can make your applications more efficient.

Coder Legion - Recent posts tagged core

How to Fix Core Web Vitals: LCP, CLS & INP | FloxoLab

What a good result looks like

The three Core Web Vitals, one at a time

LCP: how fast the main thing loads

CLS: whether the page holds still

INP: how fast the page answers you

The other numbers in the report

Lab data and field data are not the same

What actually moved this site from 77 to 98

A quick checklist

Frequently asked questions

What are Core Web Vitals?

What is a good Core Web Vitals score?

Why is my mobile score lower than desktop?

Do Core Web Vitals affect SEO rankings?

Sources checked

What Did We Lose With Abundant RAM?

Reclaiming Efficiency: A Tutorial on the Core Memory Mindset

Introduction: The Ghosts of Mainframes Past

Conceptual Walkthrough: Practicing the Core Memory Mindset

Conclusion: A Discipline for the Modern Age

🚀 EF Core Query Optimization for Beginners

1. Use AsNoTracking() for Read-Only Queries ⭐

Benefits

2. Filter Data Before Loading It

3. Project Only What You Need

4. Don't Use Include() When Projecting

5. Sort in SQL

6. Project Child Collections

7. Use Async Queries

8. Create Proper Database Indexes

Final Optimized Query

🎯 Key Takeaways

Additional Resources

5 EF Core Features Every Enterprise Developer Should Know

1. Connection Resiliency and Retry Policies

2. Optimistic Concurrency Control

3. Performance Optimization with Compiled Queries

4. Transactions and Unit of Work

5. Global Query Filters

Final Thoughts

When IDbContextFactory enters the chat, and what it actually fixes.

When IDbContextFactory enters the chat, and what it actually fixes

What problems show up

What IDbContextFactory changes

When to use it

The takeaway

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

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

8. Understanding the flow

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

10. Conclusion

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

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

Overview

Why Use System.Threading.Channels

Why Hosted Services

What is BackgroundService

What is Hangfire

1. Use `AsNoTracking()` for Read-Only Queries ⭐

4. Don't Use `Include()` When Projecting

When `IDbContextFactory` enters the chat, and what it actually fixes

What `IDbContextFactory` changes

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

What is `BackgroundService`

What is `System.Threading.Channels`