DEV Community: Spyros Ponaris

EF Core Mapping for DDD — for Dummies

Spyros Ponaris — Mon, 13 Jul 2026 19:12:37 +0000

You built a nice domain model with rules and private properties — but EF Core wants simple classes with public get; set;.

Don't worry. This guide shows you how to save DDD models to the database without messing up your code. Short sentences. Real examples. No jargon overload.

Before you start: know basic C# and what EF Core is. DDD just means putting business rules inside your C# classes instead of scattering them everywhere.

1 · What's the Problem?

DDD (Domain-Driven Design) is a fancy name for a simple idea: put your business rules inside your C# classes.

For example, "you can't ship an empty order" should live on the Order class — not in some random service file.

EF Core is the tool that saves your C# objects to SQL Server. It works great with simple classes that have public { get; set; } on everything.

But DDD classes are different — they use:

private set
factory methods like Order.Create()
hidden lists

That's where mapping comes in: a separate config file that tells EF Core "here's how to read and write my class" — without changing the class itself.

Bad model vs good model

The bad one is easy for EF Core but anyone can break the rules. The good one protects itself — EF Core just needs a little help to save it.

// ❌ BAD — no rules, anyone can change anything
public class Order
{
    public Guid Id { get; set; }
    public string Status { get; set; } = "";
    public List<OrderLine> Lines { get; set; } = [];
    // Someone can write: order.Status = "Shipped" on an empty order. Oops.
}

// ✅ GOOD — rules live here, properties are protected
public sealed class Order
{
    public OrderId Id { get; private set; }
    public OrderStatus Status { get; private set; }
    private readonly List<OrderLine> _lines = [];
    public IReadOnlyCollection<OrderLine> Lines => _lines.AsReadOnly();

    private Order() { } // EF Core needs this empty constructor — you never call it

    public static Order Create(CustomerId customerId) { /* ... */ }
    public void AddLine(ProductId productId, int qty, Money price) { /* checks rules */ }
    public void Place() { /* checks rules before shipping */ }
}

Keep database stuff out of your business code

Your Domain project (business rules) should never mention EF Core or SQL Server.

All the "how to save to the database" code goes in a separate Infrastructure project.

Think of it like this: your business code shouldn't know a database exists.

// Domain/Billing.Domain.csproj
//   → NO EntityFrameworkCore package. Just plain C#.

// Infrastructure/Billing.Infrastructure.csproj
//   → Has EF Core. References Domain. Contains mapping files.

// Example mapping file:
// Infrastructure/Persistence/Configurations/OrderConfiguration.cs

💡 Think of it like a translator. Your C# class speaks "business rules." The database speaks "tables and columns." The mapping file is the translator — and it lives in Infrastructure, not in your business code.

2 · Where Does the Code Go?

Split your solution into folders (projects):

Project	What goes here
Domain	Business classes — NO EF Core
Application	"Place order", "Cancel order" — NO EF Core
Infrastructure	EF Core and mapping files

Only the "main" object of each group gets a DbSet in EF Core. We'll explain that group (called an aggregate) in the next section.

Folder layout

src/
├── Billing.Domain/              # Business rules — NO EF Core here
│   ├── Orders/
│   │   ├── Order.cs             # The "boss" object (aggregate root)
│   │   ├── OrderLine.cs         # A line item inside an order
│   │   └── OrderId.cs           # A safe ID type (section 6)
│   └── Common/
│       └── Money.cs             # A small object with no ID (section 4)
│
├── Billing.Application/         # Handlers — NO EF Core
│
└── Billing.Infrastructure/      # EF Core lives HERE
    └── Persistence/
        ├── ApplicationDbContext.cs
        └── Configurations/
            └── OrderConfiguration.cs   # "How to save Order to SQL"

DbContext — only register the "boss" objects

DbSet means "EF Core can load and save this type directly." Only the main object (like Order) gets one. Line items (OrderLine) are saved automatically when you save the order.

public sealed class ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
    : DbContext(options)
{
    // ✅ YES — Order is the "boss" of its group
    public DbSet<Order> Orders => Set<Order>();
    public DbSet<Customer> Customers => Set<Customer>();

    // ❌ NO — OrderLine is saved through Order, not on its own
    // public DbSet<OrderLine> OrderLines => ...  DON'T DO THIS

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Finds all mapping files automatically
        modelBuilder.ApplyConfigurationsFromAssembly(typeof(ApplicationDbContext).Assembly);
    }
}

3 · The Main Object (Aggregate Root)

An aggregate is a group of objects that belong together — like an Order and its OrderLine items.

You always load and save the whole group through one "boss" object called the aggregate root. In our example, Order is the boss.

EF Core needs a private empty constructor (private Order() { }) to rebuild objects from the database. Your app code should never call it — always use Order.Create() instead.

The Order class — business rules inside

Notice: you can't change status directly. You call Place() and the class checks the rules for you.

// Domain/Orders/Order.cs
public sealed class Order : BaseEntity
{
    public OrderId Id { get; private set; }
    public CustomerId CustomerId { get; private set; }
    public OrderStatus Status { get; private set; }
    public Money Total { get; private set; } = Money.Zero;

    private readonly List<OrderLine> _lines = [];
    public IReadOnlyCollection<OrderLine> Lines => _lines.AsReadOnly();

    private Order() { } // EF Core only — your code never calls this

    public static Order Create(CustomerId customerId)
    {
        var order = new Order
        {
            Id = OrderId.New(),
            CustomerId = customerId,
            Status = OrderStatus.Draft
        };
        order.Raise(new OrderCreatedEvent(order.Id));
        return order;
    }

    public void AddLine(ProductId productId, int qty, Money unitPrice)
    {
        if (Status != OrderStatus.Draft)
            throw new DomainException("Cannot modify a placed order.");
        if (qty <= 0)
            throw new DomainException("Quantity must be positive.");

        _lines.Add(new OrderLine(productId, qty, unitPrice));
        Total = Money.Sum(_lines.Select(l => l.LineTotal));
    }

    public void Place()
    {
        if (_lines.Count == 0) throw new DomainException("Empty order.");
        Status = OrderStatus.Placed;
        Raise(new OrderPlacedEvent(Id, CustomerId, Total));
    }
}

The mapping file — tells EF Core how to save Order

This file lives in Infrastructure. It says: table name, how to save IDs, how to save Money, how to save line items, and what to ignore.

// Infrastructure/Persistence/Configurations/OrderConfiguration.cs
public sealed class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> builder)
    {
        builder.ToTable("Orders");

        builder.HasKey(o => o.Id);
        builder.Property(o => o.Id)
            .HasConversion(id => id.Value, v => new OrderId(v));

        builder.Property(o => o.CustomerId)
            .HasConversion(id => id.Value, v => new CustomerId(v));

        builder.Property(o => o.Status)
            .HasConversion<string>()
            .HasMaxLength(32);

        // Money is a small object — save it as extra columns (section 4)
        builder.OwnsOne(o => o.Total, money =>
        {
            money.Property(m => m.Amount).HasColumnName("TotalAmount").HasPrecision(18, 2);
            money.Property(m => m.Currency).HasColumnName("TotalCurrency").HasMaxLength(3);
        });

        // Line items — saved in a separate table, linked to Order
        builder.HasMany<OrderLine>("_lines")
            .WithOne()
            .HasForeignKey(l => l.OrderId)
            .OnDelete(DeleteBehavior.Cascade);

        // Events are in-memory only — don't save to database
        builder.Ignore(o => o.DomainEvents);
    }
}

⚠️ Watch out: don't make setters public just to fix an EF error. If EF Core complains about a private set, fix it in the mapping file — don't weaken your class.

4 · Small Objects With No ID (Value Objects)

Some objects don't need their own ID.

Money is just an amount and a currency.
Address is just street, city, zip.

Two Money(10, "EUR") objects are the same thing — that's a value object.

EF Core saves them as extra columns on the parent table (not a separate table). You use OwnsOne or, in .NET 8+, the simpler ComplexType.

What a value object looks like

No Id property. Just data. You can add validation in the constructor — like "street can't be empty."

// Money — just amount + currency, nothing else
public sealed record Money(decimal Amount, string Currency)
{
    public static Money Zero => new(0m, "EUR");

    public static Money Sum(IEnumerable<Money> items)
    {
        var list = items.ToList();
        if (list.Count == 0) return Zero;
        return new Money(list.Sum(m => m.Amount), list[0].Currency);
    }
}

// Address — another common value object
public sealed record Address(string Street, string City, string PostalCode, string Country)
{
    public Address(string street, string city, string postalCode, string country)
    {
        if (string.IsNullOrWhiteSpace(street)) throw new DomainException("Street required.");
        Street = street.Trim();
        City = city.Trim();
        PostalCode = postalCode.Trim();
        Country = country.Trim();
    }
}

OwnsOne — save it as extra columns

The address columns go on the Customers table — no new table needed. You pick the column names.

// Creates columns on Customers table:
//   ShipStreet, ShipCity, ShipPostalCode, ShipCountry

builder.OwnsOne(c => c.ShippingAddress, addr =>
{
    addr.Property(a => a.Street).HasColumnName("ShipStreet").HasMaxLength(200);
    addr.Property(a => a.City).HasColumnName("ShipCity").HasMaxLength(100);
    addr.Property(a => a.PostalCode).HasColumnName("ShipPostalCode").HasMaxLength(20);
    addr.Property(a => a.Country).HasColumnName("ShipCountry").HasMaxLength(60);
});

ComplexType — even easier (.NET 8+)

If you're on .NET 8 or later, slap [ComplexType] on the record and use ComplexProperty in the mapping. Less typing, same result.

[ComplexType]
public sealed record Money(decimal Amount, string Currency) { /* ... */ }

builder.ComplexProperty(o => o.Total, money =>
{
    money.Property(m => m.Amount).HasColumnName("TotalAmount").HasPrecision(18, 2);
    money.Property(m => m.Currency).HasColumnName("TotalCurrency").HasMaxLength(3);
});

// Which one to pick?
//   OwnsOne     → works on older EF Core, more options
//   ComplexType   → .NET 8+, simpler, always extra columns

OwnsMany — a list of small objects needs its own table

Usually one value object = extra columns. But if you have a list of them (like discount codes), EF Core creates a small separate table.

public sealed class Order : BaseEntity
{
    private readonly List<DiscountCode> _discounts = [];
    public IReadOnlyCollection<DiscountCode> Discounts => _discounts.AsReadOnly();
}

builder.OwnsMany(o => o.Discounts, d =>
{
    d.ToTable("OrderDiscounts");
    d.WithOwner().HasForeignKey("OrderId");
    d.Property(x => x.Code).HasMaxLength(20);
    d.Property(x => x.Percentage).HasPrecision(5, 2);
    d.HasKey("OrderId", nameof(DiscountCode.Code));
});

5 · Lists Inside an Object (Backing Fields)

Don't expose a public List<OrderLine> that anyone can add to or clear.

Instead:

Keep a private list (_lines)
Expose a read-only view (Lines)
Changes go through methods like AddLine()

EF Core can still read and write your private list — you just tell the mapping file where it is.

Private list, public read-only view

// In your Order class:
private readonly List<OrderLine> _lines = [];
public IReadOnlyCollection<OrderLine> Lines => _lines.AsReadOnly();

public void AddLine(ProductId productId, int qty, Money unitPrice)
{
    _lines.Add(new OrderLine(productId, qty, unitPrice));
}

// In your mapping file — point EF Core at "_lines"
builder.HasMany<OrderLine>("_lines")
    .WithOne()
    .HasForeignKey(l => l.OrderId)
    .OnDelete(DeleteBehavior.Cascade);

OrderLine — belongs inside Order, not on its own

OrderLine is not the "boss." You never load it directly from the database — you load the Order and its lines come with it.

public sealed class OrderLine
{
    public OrderLineId Id { get; private set; }
    public OrderId OrderId { get; private set; }
    public ProductId ProductId { get; private set; }
    public int Quantity { get; private set; }
    public Money UnitPrice { get; private set; }
    public Money LineTotal => new(Quantity * UnitPrice.Amount, UnitPrice.Currency);

    private OrderLine() { } // EF Core only

    internal OrderLine(ProductId productId, int qty, Money unitPrice)
    {
        Id = OrderLineId.New();
        ProductId = productId;
        Quantity = qty;
        UnitPrice = unitPrice;
    }
}

// Mapping file for OrderLine
public sealed class OrderLineConfiguration : IEntityTypeConfiguration<OrderLine>
{
    public void Configure(EntityTypeBuilder<OrderLine> builder)
    {
        builder.ToTable("OrderLines");
        builder.HasKey(l => l.Id);
        builder.Property(l => l.Id)
            .HasConversion(id => id.Value, v => new OrderLineId(v));
        builder.OwnsOne(l => l.UnitPrice, m => { /* column names */ });
        builder.Ignore(l => l.LineTotal); // calculated — don't save to DB
    }
}

⚠️ Watch out: don't query line items on their own. Don't add DbSet<OrderLine>. Always load the Order first.

6 · Safe IDs (No More Guid Mix-ups)

If everything is a Guid, you can accidentally pass a customer ID where an order ID is expected — and C# won't warn you.

The fix: wrap each ID in its own small type (OrderId, CustomerId). Swap them by mistake and the compiler catches it.

EF Core still saves them as plain Guid in SQL — you just add a one-line conversion in the mapping file.

Wrap your Guids

public readonly record struct OrderId(Guid Value)
{
    public static OrderId New() => new(Guid.NewGuid());
}

public readonly record struct CustomerId(Guid Value);
public readonly record struct ProductId(Guid Value);

// This won't compile — you swapped the IDs:
// void Ship(OrderId orderId, CustomerId customerId) { }
// Ship(customerId, orderId); // ❌ compiler error — saved you!

Tell EF Core how to save them

Write this helper once, then use one line per ID in every mapping file.

public static class StronglyTypedIdExtensions
{
    public static PropertyBuilder<TId> HasStronglyTypedIdConversion<TId>(
        this PropertyBuilder<TId> propertyBuilder)
        where TId : struct
    {
        var converter = new ValueConverter<TId, Guid>(
            id => (Guid)typeof(TId).GetProperty("Value")!.GetValue(id)!,
            value => (TId)Activator.CreateInstance(typeof(TId), value)!);

        return propertyBuilder.HasConversion(converter);
    }
}

// In OrderConfiguration — one line each:
builder.Property(o => o.Id).HasStronglyTypedIdConversion<OrderId>();
builder.Property(o => o.CustomerId).HasStronglyTypedIdConversion<CustomerId>();

7 · The Mapping File (Putting It All Together)

One mapping class per entity, in Infrastructure.

It answers: what table? what columns? how to save IDs and value objects? what to ignore?

Here's a complete example for Order — use it as a template.

public sealed class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> builder)
    {
        builder.ToTable("Orders", schema: "billing");

        // ID
        builder.HasKey(o => o.Id);
        builder.Property(o => o.Id).HasStronglyTypedIdConversion<OrderId>();

        // Link to Customer — just store the ID, no Customer object here
        builder.Property(o => o.CustomerId).HasStronglyTypedIdConversion<CustomerId>();

        // Status as readable text in SQL ("Draft", "Placed", ...)
        builder.Property(o => o.Status)
            .HasConversion<string>()
            .HasMaxLength(32)
            .IsRequired();

        // Money value object → extra columns
        builder.OwnsOne(o => o.Total, money =>
        {
            money.Property(m => m.Amount).HasColumnName("TotalAmount").HasPrecision(18, 2);
            money.Property(m => m.Currency).HasColumnName("TotalCurrency").HasMaxLength(3);
        });

        // Line items via private _lines field
        builder.HasMany<OrderLine>("_lines")
            .WithOne()
            .HasForeignKey(l => l.OrderId)
            .OnDelete(DeleteBehavior.Cascade);

        // Don't save events to the database
        builder.Ignore(o => o.DomainEvents);

        // Speed up common searches
        builder.HasIndex(o => o.CustomerId);
        builder.HasIndex(o => o.Status);
    }
}

What goes where?

✅ Put in mapping file (Infrastructure):

Table name
How to save IDs, enums, value objects
How to save lists (_lines)
Ignore events and calculated properties
Column sizes (MaxLength, Precision)

✅ OK to leave alone (EF guesses correctly):

int, string, bool properties
Column names same as property names

❌ Never put on Domain classes:

[Table], [Column], [ForeignKey] attributes
public setters "because EF needs them"
Any using Microsoft.EntityFrameworkCore;

8 · Saving, Loading & Mistakes to Avoid

A repository is a thin wrapper that loads and saves your "boss" objects (Order, Customer).

Your handler calls GetById, changes the object through its methods, then calls SaveChanges. That's it.

How to load, change, and save

// Interface — only works with Order, not OrderLine
public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(OrderId id, CancellationToken ct);
    void Add(Order order);
}

// Implementation
public sealed class OrderRepository(ApplicationDbContext db) : IOrderRepository
{
    public Task<Order?> GetByIdAsync(OrderId id, CancellationToken ct) =>
        db.Orders
            .Include(o => o.Lines)   // don't forget this — or lines won't load!
            .FirstOrDefaultAsync(o => o.Id == id, ct);

    public void Add(Order order) => db.Orders.Add(order);
}

// Typical flow in a handler:
var order = await repo.GetByIdAsync(cmd.OrderId, ct)
    ?? throw new NotFoundException();
order.Place();                    // business rules run here
await db.SaveChangesAsync(ct);    // EF saves changes to SQL

Domain events — memory only, not in the database

When something important happens (order placed), the class raises an event. These live in memory until SaveChanges sends them out. Never save them as a table column.

// In mapping file — always ignore events:
builder.Ignore(o => o.DomainEvents);

Quick lookup — "I have X, how do I map it?"

You have…	Map it with…
Main object (Order)	`DbSet` + mapping file
Item inside Order (Line)	`HasMany("_lines")`, no DbSet
Money, Address (no ID)	`OwnsOne` or `ComplexType`
List of small objects	`OwnsMany`
OrderId, CustomerId	`HasStronglyTypedIdConversion`
`private set` on property	works fine — don't change it
`private Order() { }`	EF Core needs it, your code doesn't
DomainEvents	`builder.Ignore(...)`
Calculated property	`builder.Ignore(...)`
Status enum	save as string
Link to another aggregate	store ID only, no `Customer` property

5 mistakes beginners make

Making everything public set — fix it in the mapping file, not the class.
DbSet for line items — only the boss object gets a DbSet.
Putting [Table] on domain classes — mapping files go in Infrastructure.
Customer property on Order — store CustomerId only, not the whole Customer object.
Forgetting .Include(o => o.Lines) — line items won't load and you'll wonder why the list is empty.

What's next?

Clean Architecture & CQRS — how the whole app fits together
EF Core In Depth — migrations, speed tips, production setup
Testing .NET — test your save/load code with a real database

Written by Spyros Ponaris — .NET Tech Lead, Athens.

🚀 EF Core Query Optimization for Beginners

Spyros Ponaris — Mon, 29 Jun 2026 19:49:02 +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

Prototype Design Pattern in C#: Cloning Objects Efficiently

Spyros Ponaris — Mon, 22 Jun 2026 08:03:16 +0000

Introduction

The Prototype Design Pattern is a creational design pattern that allows new objects to be created by copying an existing object (called a prototype) instead of creating them from scratch.

This pattern is particularly useful when:

Object creation is expensive or complex.
Many similar objects need to be created.
You want to avoid repeatedly initializing the same data.

Instead of using constructors every time, the application clones an existing object and modifies only the necessary properties.

Understanding the Prototype Pattern

The Prototype pattern works around a simple idea:

"Create new objects by cloning existing objects."

A prototype object acts as a template. When a new object is needed, the application copies the prototype and customizes it.

Structure

The following class diagram illustrates the Prototype Pattern:

Components:

Prototype (BasicCar)

Declares a cloning method.
Defines the common interface for cloning.

Concrete Prototypes (Nano, Ford)

Implement the cloning operation.
Return copies of themselves.

Client (Program)

Uses prototypes to create new objects.

Prototype Pattern Example in C

Abstract Prototype

public abstract class BasicCar
{
    public string ModelName { get; set; }
    public int Price { get; set; }

    public static int SetPrice()
    {
        int price = 0;
        Random r = new Random();
        int p = r.Next(200000, 500000);

        price = p;
        return price;
    }

    public abstract BasicCar Clone();
}

Explanation

BasicCar acts as the prototype base class.

It contains:

Common properties (ModelName, Price)
A utility method for generating random prices
An abstract Clone() method that subclasses must implement

Concrete Prototype: Ford

public class Ford : BasicCar
{
    public Ford(string m)
    {
        ModelName = m;
    }

    public override BasicCar Clone()
    {
        return (Ford)this.MemberwiseClone();
    }
}

Explanation

The Ford class inherits from BasicCar and implements the cloning logic.

return (Ford)this.MemberwiseClone();

This creates a copy of the current object using the built-in MemberwiseClone() method.

Client Code

Console.WriteLine("***Prototype Pattern Demo***\n");

// Base or Original Copy
BasicCar nano_base = new Nano("Green Nano")
{
    Price = 100000
};

BasicCar ford_base = new Ford("Ford Yellow")
{
    Price = 500000
};

BasicCar bc1;

// Nano Clone
bc1 = nano_base.Clone();
bc1.Price = nano_base.Price + BasicCar.SetPrice();

Console.WriteLine(
    "Car is: {0}, and it's price is Rs. {1}",
    bc1.ModelName,
    bc1.Price);

// Ford Clone
bc1 = ford_base.Clone();
bc1.Price = ford_base.Price + BasicCar.SetPrice();

Console.WriteLine(
    "Car is: {0}, and it's price is Rs. {1}",
    bc1.ModelName,
    bc1.Price);

Console.ReadLine();

How the Program Works

Step 1: Create Prototype Objects

BasicCar nano_base = new Nano("Green Nano");
BasicCar ford_base = new Ford("Ford Yellow");

These objects become the prototypes.

Step 2: Clone Instead of Creating

bc1 = nano_base.Clone();

Rather than creating a new Nano, we copy the existing one.

Step 3: Customize the Clone

bc1.Price = nano_base.Price + BasicCar.SetPrice();

The cloned object receives a different price while keeping the original model information.

Step 4: Repeat for Other Car Types

bc1 = ford_base.Clone();

The same cloning mechanism works for any prototype implementation.

Understanding `MemberwiseClone()`

The Prototype pattern in C# often relies on:

this.MemberwiseClone();

MemberwiseClone() is a protected method of System.Object.

It creates a shallow copy of the current object.

var copy = this.MemberwiseClone();

What Gets Copied?

Value Types

int
bool
double
struct

These are copied by value.

Original ----> 100
Clone    ----> 100

Changes to one do not affect the other.

Reference Types

List<string>
Address
Customer
Array

Only the reference is copied.

Original ---> Address Object
Clone ------^

Both objects point to the same instance.

Shallow Copy vs Deep Copy

The following comparison summarizes the difference:

Type	Meaning
Shallow Copy	Copies fields, but references stay shared
Deep Copy	Creates completely independent copies of all nested objects

Shallow Copy

public Person Clone()
{
    return (Person)this.MemberwiseClone();
}

Result:

Person A ---> Address
Person B ---^

Both persons share the same address object.

Deep Copy

public Person DeepClone()
{
    var copy = (Person)this.MemberwiseClone();

    copy.Address = new Address
    {
        City = this.Address.City
    };

    return copy;
}

Result:

Person A ---> Address A
Person B ---> Address B

Now each object has its own independent nested objects.

Is `MemberwiseClone()` Safe?

Yes, when:

Objects contain only value types.
Shared references are acceptable.
You manually clone reference-type members afterward.

Be Careful When:

Objects contain collections.
Objects contain nested objects.
Complete independence is required.

In those situations, implement a deep clone.

Benefits of the Prototype Pattern

1. Faster Object Creation

Cloning is often faster than constructing and initializing complex objects.

2. Reduces Repeated Initialization

Objects with many properties can be copied rather than rebuilt.

3. Simplifies Object Creation

Clients don't need to know all construction details.

4. Supports Runtime Object Creation

New objects can be created dynamically from existing prototypes.

Drawbacks

1. Deep Cloning Can Be Complex

Nested object graphs require extra cloning logic.

2. Shared References Can Cause Bugs

Using shallow copies incorrectly may lead to unexpected side effects.

3. Maintenance Overhead

Every new field may require updates to deep-cloning logic.

When Should You Use the Prototype Pattern?

Use Prototype when:

✅ Object creation is expensive

✅ Many similar objects are required

✅ Initialization logic is complex

✅ You need runtime object duplication

Examples include:

Game character templates
Vehicle configurations
Document templates
UI component libraries
Product catalogs

Conclusion

The Prototype Design Pattern is a powerful creational pattern that creates new objects by cloning existing ones. In C#, it is commonly implemented using MemberwiseClone(), which provides a fast and efficient way to perform shallow copies.

For simple objects, shallow cloning is often sufficient. However, when objects contain nested reference types, a deep clone should be implemented to ensure complete independence between the original object and its clone.

In the car example, Nano and Ford act as concrete prototypes, while BasicCar defines the cloning contract. The client can create new car instances efficiently by cloning existing prototypes instead of constructing them from scratch.

# Exploring a Practical Billing API Built with Modern .NET Patterns

Spyros Ponaris — Wed, 17 Jun 2026 05:59:44 +0000

The Billing repository (https://github.com/stevsharp/Billing) is a practical example of how several common .NET architectural patterns can be combined within a billing-focused application.

Built with ASP.NET Core (https://learn.microsoft.com/aspnet/core/) and Entity Framework Core (https://learn.microsoft.com/ef/core/), the project demonstrates approaches that many teams use when building modern backend services.

A Clear Project Structure

The repository follows the principles of Clean Architecture, an approach that encourages clear separation between business logic, infrastructure, and application concerns.

Learn more about Clean Architecture:
https://github.com/jasontaylordev/CleanArchitecture

This separation helps keep responsibilities organized and makes it easier to understand where different pieces of functionality belong.

Focus on Business Rules

The project incorporates concepts from Domain-Driven Design (DDD), placing important business rules within the domain layer rather than spreading them across controllers and infrastructure code.

Learn more about Domain-Driven Design:
https://martinfowler.com/bliki/DomainDrivenDesign.html

This approach helps make business behavior more explicit and encourages a design where domain concepts remain central to the application.

Using CQRS in a Simple Way

The repository demonstrates Command Query Responsibility Segregation (CQRS), separating commands (operations that modify data) from queries (operations that retrieve data).

Learn more about CQRS:
https://martinfowler.com/bliki/CQRS.html

For developers interested in learning CQRS, the project provides a straightforward implementation that is relatively easy to follow.

Reliable Event Handling

The implementation includes the Outbox Pattern, a common technique used to improve reliability when publishing events from business operations.

Learn more about the Transactional Outbox Pattern:
https://microservices.io/patterns/data/transactional-outbox.html

This pattern helps address scenarios where database changes and event publication need to remain consistent.

Multi-Tenant Considerations

Many SaaS applications need to support multiple customers while keeping their data isolated. The project includes tenant-aware functionality using authentication claims and data filtering, providing a useful reference for developers exploring multi-tenant architectures.

Learn more about multitenancy:
https://learn.microsoft.com/azure/architecture/guide/multitenant/overview

Working with Entity Framework Core

The application uses Entity Framework Core for data access and persistence. Developers looking for practical examples of EF Core usage alongside architectural patterns may find the implementation useful to study.

Learn more about EF Core:
https://learn.microsoft.com/ef/core/

Building on ASP.NET Core

The API layer is built with ASP.NET Core, Microsoft's framework for building web APIs and cloud-native applications.

Learn more about ASP.NET Core:
https://learn.microsoft.com/aspnet/core/

Good Learning Resource

One of the strengths of the repository is that it brings together several widely used concepts and patterns:

Clean Architecture
Domain-Driven Design (DDD)
CQRS
Transactional Outbox Pattern
Multi-Tenant Design
JWT Authentication
Automated Testing

Rather than presenting these ideas in isolation, the project shows how they can work together in a cohesive application.

Conclusion

The Billing repository is a helpful reference for developers who want to explore modern .NET application design. It demonstrates several architectural patterns in a practical context while remaining approachable enough to study and adapt for other projects.

Repository:
https://github.com/stevsharp/Billing

Whether you're learning these concepts for the first time or looking for implementation examples, the project offers a useful starting point for further exploration.

5 EF Core Features Every Enterprise Developer Should Know

Spyros Ponaris — Fri, 05 Jun 2026 08:49:02 +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.

Priority-Based Job Processing System in C#

Spyros Ponaris — Tue, 26 May 2026 08:53:16 +0000

This tutorial explains how to build a multithreaded, priority-based job processing system using:

PriorityQueue<TElement,TPriority>
SemaphoreSlim
Producer / Consumer pattern
Retry mechanism
Dead Letter Queue (DLQ)
Multiple workers

1. What is PriorityQueue in C#?

📌 Definition

PriorityQueue<TElement,TPriority> is a built-in .NET collection that:

Stores elements so that the item with the highest priority is dequeued first, not the one inserted first.

Official docs:
https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.priorityqueue-2?view=net-10.0

⚙️ How it works (in this system)

private readonly PriorityQueue<Job, int> _queue = new();

Jobs are added like this:

_queue.Enqueue(job, job.Priority);

Each entry has:

Element → Job
Priority → int

📊 Priority rules in .NET

👉 Lower number = higher priority

Priority	Meaning	Execution Order
1	Highest priority	First
2	Medium priority	Next
5	Low priority	Last

🧠 Simple example

var queue = new PriorityQueue<string, int>();

queue.Enqueue("Job A", 5);
queue.Enqueue("Job B", 1);
queue.Enqueue("Job C", 3);

Console.WriteLine(queue.Dequeue()); // Job B

⚠️ Important limitation

❌ PriorityQueue is NOT thread-safe
✔ This system fixes that using lock + SemaphoreSlim

2. Job Model

public record Job(
    string Name,
    int Priority,
    int RetryCount = 0,
    int MaxRetries = 3);

Why this works well

Immutable (record)
Safe for multithreading
Supports retry tracking

3. Blocking Priority Queue (Core Engine)

public class BlockingPriorityQueue
{
    private readonly PriorityQueue<Job, int> _queue = new();
    private readonly object _lock = new();
    private readonly SemaphoreSlim _signal = new(0);

Why these 3 components?

Component	Purpose
PriorityQueue	Stores jobs by priority
lock	Thread safety
SemaphoreSlim	Async waiting / signaling

➕ Enqueue (Producer side)

public void Enqueue(Job job)
{
    lock (_lock)
    {
        _queue.Enqueue(job, job.Priority);
        _signal.Release();
    }
}

Flow

Producer → lock → enqueue → signal workers

➖ Dequeue (Consumer side)

public async Task<Job> DequeueAsync(CancellationToken cancellationToken = default)
{
    await _signal.WaitAsync(cancellationToken);

    lock (_lock)
    {
        return _queue.Dequeue();
    }
}

Flow

Worker waits → signal → lock → dequeue highest priority job

4. Dead Letter Queue (DLQ)

public class DeadLetterQueue
{
    private readonly List<Job> _failedJobs = new();

    public void Add(Job job, Exception ex)
    {
        Console.WriteLine($"DLQ: Job {job.Name} failed permanently: {ex.Message}");
        _failedJobs.Add(job);
    }

    public IReadOnlyList<Job> GetAll() => _failedJobs;
}

Purpose

DLQ stores jobs that:

exceeded retry limit
failed permanently
require manual inspection

5. Job Processor (Worker System)

public class JobProcessor(BlockingPriorityQueue jobQueue, DeadLetterQueue deadLetterQueue)
{
    private readonly BlockingPriorityQueue _jobQueue = jobQueue;
    private readonly DeadLetterQueue _deadLetterQueue = deadLetterQueue;

Main processing loop

public async Task ProcessJobsAsync(CancellationToken cancellationToken = default)
{
    while (!cancellationToken.IsCancellationRequested)
    {
        try
        {
            var job = await _jobQueue.DequeueAsync(cancellationToken);

            await ProcessJob(job, cancellationToken);
        }
        catch (OperationCanceledException)
        {
            Console.WriteLine("Job processing cancelled.");
            break;
        }
    }
}

Job execution logic

private async Task ProcessJob(Job job, CancellationToken ct)
{
    try
    {
        Console.WriteLine($"Processing {job.Name}");

        await Task.Delay(500, ct);

        if (Random.Shared.Next(0, 3) == 0)
            throw new Exception("Random failure");

        Console.WriteLine($"✅ Success: {job.Name}");
    }
    catch (Exception ex)
    {
        await HandleFailure(job, ex);
    }
}

6. Retry Logic

private async Task HandleFailure(Job job, Exception ex)
{
    if (job.RetryCount < job.MaxRetries)
    {
        var retryJob = job with
        {
            RetryCount = job.RetryCount + 1
        };

        Console.WriteLine($"Retrying {job.Name} ({retryJob.RetryCount})");

        await Task.Delay(1000);

        _jobQueue.Enqueue(retryJob);
    }
    else
    {
        _deadLetterQueue.Add(job, ex);
    }
}

Behavior flow

Failure → retry → requeue → success OR DLQ

7. Job Producer

public class JobProducer(BlockingPriorityQueue jobQueue, DeadLetterQueue deadLetterQueue)
{
    private readonly BlockingPriorityQueue _jobQueue = jobQueue;
    private readonly DeadLetterQueue _deadLetterQueue = deadLetterQueue;

Publish single job

public void PublishJob(string name, int priority)
{
    var job = new Job(name, priority);

    Console.WriteLine($"Publishing {job.Name} with priority {job.Priority}");

    _jobQueue.Enqueue(job);
}

Publish multiple jobs

public void PublishJobs(IEnumerable<Job> jobs)
{
    foreach (var job in jobs)
    {
        Console.WriteLine($"Publishing {job.Name} with priority {job.Priority}");
        _jobQueue.Enqueue(job);
    }
}

Manual DLQ injection

public void PublishDeadLetterJob(string name, int priority)
{
    var job = new Job(name, priority);

    Console.WriteLine($"Publishing {job.Name} to DLQ");

    _deadLetterQueue.Add(job, new Exception("Manually added"));
}

8. System Execution

Setup

var queue = new BlockingPriorityQueue();
var dlq = new DeadLetterQueue();
var jobProducer = new JobProducer(queue, dlq);
var cts = new CancellationTokenSource();

Start workers

var job1 = new JobProcessor(queue, dlq);
var job2 = new JobProcessor(queue, dlq);

var workerTasks = new[]
{
    Task.Run(() => job1.ProcessJobsAsync(cts.Token)),
    Task.Run(() => job2.ProcessJobsAsync(cts.Token))
};

Publish jobs

for (int i = 0; i < 10; i++)
{
    var priority = Random.Shared.Next(1, 5);

    Console.WriteLine($"\nPublishing Job - {i} with priority {priority}");

    jobProducer.PublishJob($"Job - {i}", priority);
}

Shutdown system

await Task.Delay(3000);

cts.Cancel();

await Task.WhenAll(workerTasks);

Console.WriteLine("System stopped cleanly.");

9. Runtime behavior

Jobs are published with random priority
Stored in PriorityQueue
Workers wait asynchronously
Highest priority job executes first
Random failures occur
Failed jobs retry if allowed
Permanent failures go to DLQ
System shuts down gracefully

10. Key Concepts Learned

✔ PriorityQueue

Built-in heap structure for priority-based scheduling

✔ Thread Safety

Handled using:

lock
SemaphoreSlim

✔ Producer / Consumer

Producer → JobProducer
Consumer → JobProcessor

✔ Retry System

Automatic retry with counter tracking

✔ Dead Letter Queue

Stores failed jobs permanently

✔ Multithreading

Multiple workers process jobs concurrently

✔ Graceful Shutdown

Uses CancellationTokenSource

🚀 Summary

Real-world style system that includes:

Priority scheduling
Concurrent workers
Async processing
Retry logic
Failure isolation (DLQ)
Thread-safe queue coordination

*Full Implementation *

public record Job(string Name,int Priority,int RetryCount = 0, int MaxRetries = 3);
/// <summary>
/// 
/// </summary>
public class BlockingPriorityQueue
{
    /// <summary>
    /// 
    /// </summary>
    private readonly PriorityQueue<Job, int> _queue = new();
    /// <summary>
    /// 
    /// </summary>
    private readonly object _lock = new();
    /// <summary>
    /// 
    /// </summary>
    private readonly SemaphoreSlim _signal = new(0);

    public void Enqueue(Job job)
    {
        lock (_lock)
        {
            _queue.Enqueue(job, job.Priority);

            _signal.Release();
        }
    }

    public async Task<Job> DequeueAsync(CancellationToken cancellationToken = default) { 

        await _signal.WaitAsync(cancellationToken);

        lock (_lock)
        {
            return _queue.Dequeue();
        }
    }
}


public class DeadLetterQueue
{
    private readonly List<Job> _failedJobs = new();

    public void Add(Job job, Exception ex)
    {
        Console.WriteLine($"DLQ: Job {job.Name} failed permanently: {ex.Message}");
        _failedJobs.Add(job);
    }

    public IReadOnlyList<Job> GetAll() => _failedJobs;
}


public class JobProcessor(BlockingPriorityQueue jobQueue, DeadLetterQueue deadLetterQueue)
{
    private readonly BlockingPriorityQueue _jobQueue = jobQueue;

    private readonly DeadLetterQueue _deadLetterQueue = deadLetterQueue;

    public async Task ProcessJobsAsync(CancellationToken cancellationToken = default)
    {
        while (!cancellationToken.IsCancellationRequested)
        {
            try
            {
               var job = await _jobQueue.DequeueAsync(cancellationToken);
                if (job != null) 
                { 
                    await ProcessJob(job, cancellationToken);
                }
            }
            catch (OperationCanceledException)
            {
                Console.WriteLine("Job processing cancelled.");
                break;
            }
        }
    }

    private async Task ProcessJob(Job job, CancellationToken ct)
    {

        try
        {
            Console.WriteLine($"Processing {job.Name}");

            // Simulate work
            // In a real implementation, this would be where the actual job logic goes
            // For demonstration, we just delay for a short time
            // http Call .. database operation .. etc
            await Task.Delay(500, ct);

            // Simulate random failure
            if (Random.Shared.Next(0, 3) == 0)
                throw new Exception("Random failure");

            Console.WriteLine($"✅ Success: {job.Name}");
        }
        catch (Exception ex)
        {
            await HandleFailure(job, ex);
        }
    }

    private async Task HandleFailure(Job job, Exception ex)
    {
        if (job.RetryCount < job.MaxRetries)
        {
            var retryJob = job with { RetryCount = job.RetryCount + 1 };

            Console.WriteLine($"Retrying {job.Name} ({retryJob.RetryCount})");

            await Task.Delay(1000);

            _jobQueue.Enqueue(retryJob);
        }
        else
        {
            _deadLetterQueue.Add(job, ex);
        }
    }


    public class JobProducer(BlockingPriorityQueue jobQueue, DeadLetterQueue deadLetterQueue)
    {
        /// <summary>
        /// Thread-safe priority queue for managing jobs.   
        /// </summary>
        /// <remarks>Enables prioritized job processing in concurrent scenarios.</remarks>
        private readonly BlockingPriorityQueue _jobQueue = jobQueue;
        /// <summary>
        /// 
        /// </summary>
        private readonly DeadLetterQueue _deadLetterQueue = deadLetterQueue;
        /// <summary>
        /// Publishes a collection of jobs to the job queue.
        /// </summary>
        /// <param name="jobs">The jobs to be published.</param>
        public void PublishJobs(IEnumerable<Job> jobs)
        {
            foreach (var job in jobs)
            {
                Console.WriteLine($"Publishing {job.Name} with priority {job.Priority}");

                _jobQueue.Enqueue(job);
            }
        }

        public void PublishJob(string name, int priority)
        {
            var job = new Job(name, priority);

            Console.WriteLine($"Publishing {job.Name} with priority {job.Priority}");

            _jobQueue.Enqueue(job);
        }

        public void PublishDeadLetterJob(string name, int priority)
        {
            var job = new Job(name, priority);
            Console.WriteLine($"Publishing {job.Name} to DLQ with priority {job.Priority}");
            _deadLetterQueue.Add(job, new Exception("Manually added to DLQ"));
        }
    }
}

var queue = new BlockingPriorityQueue();
var dlq = new DeadLetterQueue();
var jobProducer = new JobProducer(queue, dlq);
var cts = new CancellationTokenSource();

try
{
    var job1 = new JobProcessor(queue, dlq);
    var job2 = new JobProcessor(queue, dlq);

    var workerTasks = new[]
    {
        Task.Run(() => job1.ProcessJobsAsync(cts.Token)),
        Task.Run(() => job2.ProcessJobsAsync(cts.Token))
    };

    // Publish jobs
    for (int i = 0; i < 10; i++)
    {
        var priority = Random.Shared.Next(1, 5);

        Console.BackgroundColor = ConsoleColor.Green;
        Console.WriteLine(Environment.NewLine + $"Publishing Job - {i} with priority {priority}");
        Console.WriteLine($"Publishing Job - {i} with priority {priority}");
        Console.ResetColor();   
        jobProducer.PublishJob($"Job - {i}", priority);
    }

    await Task.Delay(3000);

    cts.Cancel();

    await Task.WhenAll(workerTasks);

    Console.WriteLine("System stopped cleanly.");
}
catch (OperationCanceledException)
{
    Console.WriteLine("Processing cancelled.");
}
catch (Exception ex)
{
    Console.WriteLine($"Error: {ex.Message}");
}

Console.ReadKey();

Blazor Latest Features

Spyros Ponaris — Tue, 19 May 2026 08:13:57 +0000

Blazor Latest Features

Blazor, Microsoft’s modern web UI framework, has evolved significantly in recent releases (.NET 8 and .NET 9). It now provides a powerful mix of full-stack capabilities, flexible rendering, and high performance, making it a strong alternative to JavaScript-based frameworks.

1. Unified Full-Stack Blazor

With .NET 8, Blazor became a full-stack framework that unifies server and client rendering within a single project.

Supported rendering models:

Static Server-Side Rendering (SSR)
Interactive Server
Interactive WebAssembly
Interactive Auto (hybrid)

Developers can now choose the best rendering strategy per component, improving both performance and flexibility.

⚙️ 2. Advanced Rendering Modes

Blazor introduces powerful rendering options:

Static SSR → Fast HTML, SEO-friendly
Interactive Server → Real-time updates via SignalR
Interactive WebAssembly → Runs fully in the browser
Auto Mode → Switches dynamically between server and client

✅ This enables hybrid applications where static content and interactive UI coexist seamlessly.

⚡ 3. Streaming Rendering

Blazor supports streaming SSR, allowing content to be delivered progressively while data loads.

Benefits:

Faster perceived load time
Better user experience for data-heavy apps
Improved responsiveness

4. Performance Improvements

Recent versions include major performance enhancements:

Faster startup times (WebAssembly optimizations)
Smaller application bundles
Improved rendering efficiency
Optimized static file delivery

Result: faster apps and better scalability

5. New Blazor Web App Template

The new unified template simplifies development:

Single project structure
Built-in rendering configuration
Reduced setup complexity

✅ Ideal for modern full-stack applications.

6. Better Developer Experience

Blazor now includes:

Constructor-based dependency injection
Improved debugging and diagnostics
Simplified authentication handling
Cleaner component architecture

Makes development faster and more maintainable.

7. Improved Interactivity

Enhancements in .NET 9:

Better reconnection handling
Improved routing and navigation
Enhanced state management

✅ Applications are more stable and responsive.

8. Cross-Platform & Hybrid Apps

Blazor integrates with .NET MAUI, allowing apps to run on:

Web
Desktop
Mobile

One codebase across multiple platforms.

9. Blazor UI Component Libraries

Blazor’s ecosystem includes powerful UI libraries that accelerate development.

MudBlazor (Open Source)

A popular Material Design component library.

Features:

Modern UI components (DataGrid, Dialogs, Forms)
Pure C# (minimal JavaScript)
Easy setup
Open-source

✅ Best for:

Dashboards
Admin panels
Rapid development

Syncfusion Blazor

Enterprise-grade UI component suite.

Features:

80+ components (Grid, Charts, Scheduler, etc.)
High-performance data handling
Built-in AI-enhanced components
Excellent documentation

✅ Best for:

Enterprise apps
Data-intensive dashboards
Reporting systems

DevExpress Blazor

Professional enterprise UI library.

Features:

Advanced DataGrid and TreeList
Reporting tools
High performance
Accessibility improvements

✅ Best for:

Large-scale business applications
Complex data visualization

✅ Conclusion

Blazor has evolved into a modern, enterprise-ready full-stack framework.

Key strengths:

✅ Flexible rendering (SSR + WASM)
✅ Strong performance improvements
✅ Simplified developer experience
✅ Rich UI component ecosystem

With libraries like MudBlazor, Syncfusion, and DevExpress, developers can build powerful applications faster than ever.

Abstract Factory Pattern in C# – Step-by-Step Tutorial

Spyros Ponaris — Mon, 11 May 2026 08:20:18 +0000

Abstract Factory Pattern in C# – Step-by-Step Tutorial (Using My Project)

In this tutorial, I’ll explain how I implemented the Abstract Factory Pattern in C# using my project:

GitHub Repository: https://github.com/stevsharp/AbstractFactoryDemo

This project demonstrates how to support multiple database providers like:

SQL Server
MySQL

Each database needs related objects such as:

Database Connection
Database Command

Instead of hardcoding these objects directly, we use the Abstract Factory Pattern to make the code cleaner and scalable.

Step 1: The Problem

Imagine your application supports multiple databases.

Without using Abstract Factory, your code may look like this:

if(databaseType == "SQL")
{
    var connection = new SqlConnection();
    var command = new SqlCommand();
}
else
{
    var connection = new MySqlConnection();
    var command = new MySqlCommand();
}

Why this is bad:

Too many if/else statements
Hard to maintain
Difficult to scale
Tight coupling with concrete classes

We need a better approach.

Step 2: Create Abstract Products

These interfaces define common behavior for all database implementations.

IDbConnection.cs

public interface IDbConnection
{
    void Connect();
}

IDbCommand.cs

public interface IDbCommand
{
    void Execute();
}

Now every database provider must implement these interfaces.

Step 3: Create SQL Server Products

SqlConnection.cs

public class SqlConnection : IDbConnection
{
    public void Connect()
    {
        Console.WriteLine("Connecting to SQL Server...");
    }
}

SqlCommand.cs

public class SqlCommand : IDbCommand
{
    public void Execute()
    {
        Console.WriteLine("Executing SQL command...");
    }
}

These classes handle SQL Server operations.

Step 4: Create MySQL Products

MySqlConnection.cs

public class MySqlConnection : IDbConnection
{
    public void Connect()
    {
        Console.WriteLine("Connecting to MySQL...");
    }
}

MySqlCommand.cs

public class MySqlCommand : IDbCommand
{
    public void Execute()
    {
        Console.WriteLine("Executing MySQL command...");
    }
}

These classes handle MySQL operations.

Step 5: Create the Abstract Factory

Now we create a factory interface.

IDatabaseFactory.cs

public interface IDatabaseFactory
{
    IDbConnection CreateConnection();
    IDbCommand CreateCommand();
}

This ensures every factory creates:

Connection objects
Command objects

Step 6: Create SQL Server Factory

SqlServerFactory.cs

public class SqlServerFactory : IDatabaseFactory
{
    public IDbConnection CreateConnection()
    {
        return new SqlConnection();
    }

    public IDbCommand CreateCommand()
    {
        return new SqlCommand();
    }
}

This factory creates SQL-related objects.

Step 7: Create MySQL Factory

MySqlFactory.cs

public class MySqlFactory : IDatabaseFactory
{
    public IDbConnection CreateConnection()
    {
        return new MySqlConnection();
    }

    public IDbCommand CreateCommand()
    {
        return new MySqlCommand();
    }
}

This factory creates MySQL-related objects.

Step 8: Use the Factory in Client Code

Now the client works with the factory instead of concrete classes.

Program.cs

class Program
{
    static void Main()
    {
        IDatabaseFactory factory = new MySqlFactory();

        var connection = factory.CreateConnection();
        var command = factory.CreateCommand();

        connection.Connect();
        command.Execute();
    }
}

Output

Connecting to MySQL...
Executing MySQL command...

Step 9: Why This Pattern Is Useful

Let’s say your application needs to support PostgreSQL in the future.

You would simply add:

PostgresConnection
PostgresCommand
PostgresFactory

And your client code stays exactly the same.

That makes your code:

✅ Flexible
✅ Maintainable
✅ Scalable
✅ Easy to test

Visual Flow

Client
   ↓
IDatabaseFactory
   ↓
--------------------------------
↓                              ↓
SqlServerFactory         MySqlFactory
↓                              ↓
SqlConnection            MySqlConnection
SqlCommand               MySqlCommand

Real Interview Explanation

Here’s how you can explain this in an interview:

In this project, I used the Abstract Factory Pattern to create families of related database objects. Each database provider creates its own connection and command objects. This reduces tight coupling and makes the application easier to extend when adding new databases.

When Should You Use Abstract Factory?

Use Abstract Factory when:

You need to create families of related objects
You want loose coupling
Your system supports multiple implementations
You want easier scalability

Examples:

Database providers
UI themes
Payment gateways
Cloud providers

Final Thoughts

Abstract Factory is a great design pattern when your application needs flexibility.

Instead of hardcoding object creation logic everywhere, you centralize it through factories and keep your code clean.

If you want to see the full implementation, check out the repository:

https://github.com/stevsharp/AbstractFactoryDemo

Reference

https://refactoring.guru/design-patterns/abstract-factory

This version is fully formatted for Dev.to Markdown, so you can paste it directly into your article editor.

Refactoring a Simple C# Method Step by Step

Spyros Ponaris — Wed, 06 May 2026 09:01:29 +0000

Refactoring in C# — Step by Step Guide

Refactoring is not about changing what the code does. It is about improving how the code is written.

The goal is to make the code easier to read, easier to test, and easier to maintain.

In this tutorial, we will refactor a simple user registration method step by step.

The Original Code

Imagine we have a method like this:

public void RegisterUser(string username, string password, int age, string email)
{
    if (username == null || username == "")
        throw new Exception("Username is required");

    if (password == null || password == "")
        throw new Exception("Password is required");

    if (password.Length < 8)
        throw new Exception("Password must be at least 8 characters");

    if (age < 18 || age > 120)
        throw new Exception("Invalid age");

    if (email == null || !email.Contains("@") || !email.Contains("."))
        throw new Exception("Invalid email");

    Console.WriteLine("User registered successfully!");
}

The code works, but it has some problems.

What Is Wrong With This Code?

The method has too many responsibilities:

It validates input
It performs business logic
It mixes concerns

This makes it harder to read and test.

Other issues:

Validation logic is mixed with business logic
The method is too long
Repeated checks
Primitive obsession (string, int instead of domain types)

Step 1: Use Guard Clauses

public void RegisterUser(string username, string password, int age, string email)
{
    ArgumentException.ThrowIfNullOrWhiteSpace(username);
    ArgumentException.ThrowIfNullOrWhiteSpace(password);

    if (password.Length < 8)
        throw new ArgumentException("Password must be at least 8 characters.", nameof(password));

    if (age is < 18 or > 120)
        throw new ArgumentOutOfRangeException(nameof(age));

    if (!IsValidEmail(email))
        throw new FormatException("Invalid email format.");

    Console.WriteLine("User registered successfully!");
}

private bool IsValidEmail(string email)
{
    return !string.IsNullOrWhiteSpace(email)
           && email.Contains("@")
           && email.Contains(".");
}

Step 2: Use a Request Object (DTO)

public class UserRegistrationRequest
{
    public string Username { get; set; } = string.Empty;
    public string Password { get; set; } = string.Empty;
    public int Age { get; set; }
    public string Email { get; set; } = string.Empty;
}

Updated method:

public void RegisterUser(UserRegistrationRequest request)
{
    ArgumentNullException.ThrowIfNull(request);

    ArgumentException.ThrowIfNullOrWhiteSpace(request.Username);
    ArgumentException.ThrowIfNullOrWhiteSpace(request.Password);

    if (request.Password.Length < 8)
        throw new ArgumentException("Password must be at least 8 characters.");

    if (request.Age is < 18 or > 120)
        throw new ArgumentOutOfRangeException(nameof(request.Age));

    if (!IsValidEmail(request.Email))
        throw new FormatException("Invalid email format.");

    Console.WriteLine("User registered successfully!");
}

Step 3: Extract Validation Into a Validator

public class UserRegistrationValidator
{
    public void Validate(UserRegistrationRequest request)
    {
        ArgumentNullException.ThrowIfNull(request);

        ArgumentException.ThrowIfNullOrWhiteSpace(request.Username);
        ArgumentException.ThrowIfNullOrWhiteSpace(request.Password);

        if (request.Password.Length < 8)
            throw new ArgumentException("Password must be at least 8 characters.");

        if (request.Age is < 18 or > 120)
            throw new ArgumentOutOfRangeException(nameof(request.Age));

        if (!IsValidEmail(request.Email))
            throw new FormatException("Invalid email format.");
    }

    private static bool IsValidEmail(string email)
    {
        return !string.IsNullOrWhiteSpace(email)
               && email.Contains("@")
               && email.Contains(".");
    }
}

Service:

public void RegisterUser(UserRegistrationRequest request)
{
    var validator = new UserRegistrationValidator();
    validator.Validate(request);

    Console.WriteLine("User registered successfully!");
}

Step 4: Inject the Validator

public interface IUserRegistrationValidator
{
    void Validate(UserRegistrationRequest request);
}

public class UserRegistrationValidator : IUserRegistrationValidator
{
    public void Validate(UserRegistrationRequest request)
    {
        ArgumentNullException.ThrowIfNull(request);

        ArgumentException.ThrowIfNullOrWhiteSpace(request.Username);
        ArgumentException.ThrowIfNullOrWhiteSpace(request.Password);

        if (request.Password.Length < 8)
            throw new ArgumentException("Password must be at least 8 characters.");

        if (request.Age is < 18 or > 120)
            throw new ArgumentOutOfRangeException(nameof(request.Age));

        if (!IsValidEmail(request.Email))
            throw new FormatException("Invalid email format.");
    }

    private static bool IsValidEmail(string email)
    {
        return !string.IsNullOrWhiteSpace(email)
               && email.Contains("@")
               && email.Contains(".");
    }
}

public class UserRegistrationService
{
    private readonly IUserRegistrationValidator _validator;

    public UserRegistrationService(IUserRegistrationValidator validator)
    {
        _validator = validator;
    }

    public void RegisterUser(UserRegistrationRequest request)
    {
        _validator.Validate(request);
        Console.WriteLine("User registered successfully!");
    }
}

Step 5: Value Objects

public sealed record Email
{
    public string Value { get; }

    public Email(string value)
    {
        if (string.IsNullOrWhiteSpace(value) ||
            !value.Contains("@") ||
            !value.Contains("."))
        {
            throw new FormatException("Invalid email format.");
        }

        Value = value;
    }

    public override string ToString() => Value;
}

public sealed record Password
{
    public string Value { get; }

    public Password(string value)
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Password is required.");

        if (value.Length < 8)
            throw new ArgumentException("Password must be at least 8 characters.");

        Value = value;
    }
}

Step 6: Specification Pattern

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

public class AgeSpecification : ISpecification<int>
{
    public bool IsSatisfiedBy(int age)
    {
        return age is >= 18 and <= 120;
    }
}

Step 7: Result Pattern

public record Result(bool Success, string Error)
{
    public static Result Ok() => new(true, string.Empty);
    public static Result Fail(string error) => new(false, error);
}

public Result RegisterUser(UserRegistrationRequest request)
{
    if (string.IsNullOrWhiteSpace(request.Username))
        return Result.Fail("Username is required.");

    if (string.IsNullOrWhiteSpace(request.Password))
        return Result.Fail("Password is required.");

    return Result.Ok();
}

Final Service

public class UserRegistrationService
{
    private readonly IUserRegistrationValidator _validator;

    public UserRegistrationService(IUserRegistrationValidator validator)
    {
        _validator = validator;
    }

    public void RegisterUser(UserRegistrationRequest request)
    {
        _validator.Validate(request);
        Console.WriteLine("User registered successfully!");
    }
}

Summary

Technique	Benefit
Guard Clauses	Fail fast validation
DTO	Cleaner input structure
Validator	Separation of concerns
DI	Better testability
Value Objects	Stronger domain rules
Specification Pattern	Flexible business rules
Result Pattern	Better API/UI flow

Bonus: State Pattern Example

Initial code :

foreach (char c in input)
        {
            if (c == '[')
            {
                insideBrackets = true;
                currentValue.Clear();
            }
            else if (c == ']' && insideBrackets)
            {
                results.Add(currentValue.ToString());
                insideBrackets = false;
            }
            else if (insideBrackets)
            {
                currentValue.Append(c);
            }
        }

        return results;

public class ParserContext
{
    public List<string> Results { get; } = new();
    public StringBuilder Current { get; } = new();
    public IParserState State { get; set; } = new OutsideState();

    public void Process(char c) => State.Handle(this, c);
}

public interface IParserState
{
    void Handle(ParserContext ctx, char c);
}

public class OutsideState : IParserState
{
    public void Handle(ParserContext ctx, char c)
    {
        if (c == '[')
        {
            ctx.Current.Clear();
            ctx.State = new InsideState();
        }
    }
}

public class InsideState : IParserState
{
    public void Handle(ParserContext ctx, char c)
    {
        if (c == ']')
        {
            ctx.Results.Add(ctx.Current.ToString());
            ctx.State = new OutsideState();
        }
        else
        {
            ctx.Current.Append(c);
        }
    }
}

Usage :

var input = "Hello [John] and [Mary]";

var context = new ParserContext();

foreach (char c in input)
{
    context.Process(c);
}

foreach (var result in context.Results)
{
    Console.WriteLine(result);
}

Conclusion

Start simple:

Guard clauses first
Extract methods next
Then introduce DTOs
Then validators
Then value objects
Then patterns (Specification, State, etc.)

Good refactoring makes code simpler, not more complicated.

The Rule Pattern in C#

Spyros Ponaris — Tue, 28 Apr 2026 09:12:19 +0000

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

Business rules have a bad habit of spreading everywhere. A little validation in a command handler, another check in a service, one more if in the entity, and before long the real policy of the system is buried under conditionals. The Rule pattern solves that by giving each business rule its own object and a clear name. In practice, this style is very close to what Fowler describes as the Specification pattern, especially when you start combining rules with AND, OR, and NOT. (martinfowler.com)

At the same time, many of us do not want to throw exceptions for expected business failures. That is where the Result pattern fits naturally. Instead of throwing, we return a success or failure object that makes the outcome explicit to the caller. This is a common way to model expected failures in application code. (Enterprise Craftsmanship)

Put those two together, and the design becomes very clean:

Rule pattern decides whether something is allowed
Result pattern communicates the outcome back to the caller

That combination is not a formal framework rule, but it is a very practical pairing. One expresses business intent, the other expresses application flow. (martinfowler.com)

So, what is the Rule pattern?

The Rule pattern wraps one business condition in one class.

Instead of writing this:

if (order.TotalAmount < 50m)
    return Result.Failure("Order must be at least 50.");

if (!order.Customer.IsVerified)
    return Result.Failure("Customer must be verified.");

if (order.Customer.CurrentBalance + order.TotalAmount > order.Customer.CreditLimit)
    return Result.Failure("Credit limit exceeded.");

You move each rule into its own object:

public interface IRule<T>
{
    bool IsSatisfiedBy(T entity);
    string ErrorMessage { get; }
}

That interface is tiny, but it already gives you two important things: a way to evaluate a business rule, and a way to describe why it failed.

This is the heart of the pattern. A rule becomes a first-class concept in the codebase instead of just another anonymous if. Fowler’s Specification write-up is essentially about doing exactly this, making business criteria explicit and composable. (martinfowler.com)

A base class makes rules composable

Your BaseRule<T> adds the nice part:

public abstract class BaseRule<T> : IRule<T>
{
    public abstract bool IsSatisfiedBy(T entity);
    public abstract string ErrorMessage { get; }

    public BaseRule<T> And(IRule<T> other) => new AndRule<T>(this, other);
    public BaseRule<T> Or(IRule<T> other) => new OrRule<T>(this, other);
    public BaseRule<T> Not() => new NotRule<T>(this);
}

Now a rule is no longer just a check. It is a building block. You can combine simple rules into richer business policies, which is one of the main strengths of Specification-style modeling. (martinfowler.com)

That means your code can start reading more like the business itself:

var rule = new OrderMinimumAmountRule(50m)
    .And(new CustomerVerifiedRule())
    .And(new CreditLimitRule());

This is much easier to understand than a long block of unrelated conditions.

The supporting rule combinators

Your AndRule<T> is straightforward:

public class AndRule<T> : BaseRule<T>
{
    private readonly IRule<T> _left, _right;
    public AndRule(IRule<T> left, IRule<T> right) => (_left, _right) = (left, right);

    public override bool IsSatisfiedBy(T entity) =>
        _left.IsSatisfiedBy(entity) && _right.IsSatisfiedBy(entity);

    public override string ErrorMessage =>
        _left.ErrorMessage + "; " + _right.ErrorMessage;
}

This says both rules must pass.

Your OrRule<T> says at least one rule must pass:

public class OrRule<T> : BaseRule<T>
{
    private readonly IRule<T> _left, _right;
    public OrRule(IRule<T> left, IRule<T> right) => (_left, _right) = (left, right);

    public override bool IsSatisfiedBy(T entity) =>
        _left.IsSatisfiedBy(entity) || _right.IsSatisfiedBy(entity);

    public override string ErrorMessage => _left.ErrorMessage;
}

And NotRule<T> flips the result:

public class NotRule<T> : BaseRule<T>
{
    private readonly IRule<T> _inner;
    public NotRule(IRule<T> inner) => _inner = inner;

    public override bool IsSatisfiedBy(T entity) => !_inner.IsSatisfiedBy(entity);
    public override string ErrorMessage => $"Negated: {_inner.ErrorMessage}";
}

Conceptually, this is exactly the kind of composite behavior Fowler describes for specifications. (martinfowler.com)

A real example, order placement

Let’s say your domain has three simple rules:

The order must be at least 50
The customer must be verified
The customer must stay within their credit limit

Those rules become very small classes:

public sealed class OrderMinimumAmountRule : BaseRule<Order>
{
    private readonly decimal _minimumAmount;

    public OrderMinimumAmountRule(decimal minimumAmount)
    {
        _minimumAmount = minimumAmount;
    }

    public override bool IsSatisfiedBy(Order order)
        => order.TotalAmount >= _minimumAmount;

    public override string ErrorMessage
        => $"Order must be at least {_minimumAmount:C}.";
}

public sealed class CustomerVerifiedRule : BaseRule<Order>
{
    public override bool IsSatisfiedBy(Order order)
        => order.Customer.IsVerified;

    public override string ErrorMessage
        => "Customer must be verified.";
}

public sealed class CreditLimitRule : BaseRule<Order>
{
    public override bool IsSatisfiedBy(Order order)
        => order.Customer.CurrentBalance + order.TotalAmount <= order.Customer.CreditLimit;

    public override string ErrorMessage
        => "Credit limit exceeded.";
}

Each class has one job. Each class is easy to test. Each class has a business name, not a technical name. That clarity is one of the biggest wins of this pattern. (martinfowler.com)

Where the Result pattern enters the picture

A rule can tell us whether the order is valid. But something still has to return that outcome to the caller.

That is where Result becomes useful.

Your handler already shows the idea well:

public class PlaceOrderCommandHandler(
    IOrderRepository orders,
    ICustomerRepository customers) : ICommandHandler<PlaceOrderCommand>
{
    private readonly IOrderRepository _orders = orders;
    private readonly ICustomerRepository _customers = customers;

    public async Task<Result> Handle(PlaceOrderCommand command, CancellationToken cancellationToken)
    {
        var customer = await _customers.GetByIdAsync(command.CustomerId, cancellationToken);
        if (customer is null)
            return Result.Failure("Customer not found.");

        var lines = command.Lines.Select(l => OrderLine.Create(l.ProductId, l.Quantity, l.UnitPrice));
        var order = Order.Draft(customer, lines);

        var rule = new OrderMinimumAmountRule(50m)
            .And(new CustomerVerifiedRule())
            .And(new CreditLimitRule());

        if (!rule.IsSatisfiedBy(order))
            return Result.Failure(rule.ErrorMessage);

        order.Place();
        await _orders.AddAsync(order, cancellationToken);

        return Result.Success();
    }
}

This reads nicely because the responsibilities are split cleanly. The rule answers, “Is this order allowed?” The result answers, “What happened when we tried?” That aligns well with Result-based error handling, where expected failures are returned explicitly instead of being hidden behind exceptions. (Enterprise Craftsmanship)

Why these two patterns fit together so naturally

The Rule pattern is about decision making.

The Result pattern is about outcome modeling.

That distinction matters.

A rule does not need to know anything about HTTP, APIs, UI messages, or pipeline behavior. It just checks business truth. The application layer then takes that truth and wraps it in a Result, which can be returned to a controller, endpoint, or caller in a predictable way. That separation lines up well with layered DDD guidance, where the application layer coordinates work and the domain layer holds the business logic. (Microsoft Learn)

A small refinement that makes the pairing even better

One nice improvement is to teach rules how to convert themselves into a Result.

For example:

public static class RuleExtensions
{
    public static Result ToResult<T>(this IRule<T> rule, T entity)
    {
        return rule.IsSatisfiedBy(entity)
            ? Result.Success()
            : Result.Failure(rule.ErrorMessage);
    }
}

Then the handler becomes even cleaner:

public async Task<Result> Handle(PlaceOrderCommand command, CancellationToken cancellationToken)
{
    var customer = await _customers.GetByIdAsync(command.CustomerId, cancellationToken);
    if (customer is null)
        return Result.Failure("Customer not found.");

    var lines = command.Lines.Select(l => OrderLine.Create(l.ProductId, l.Quantity, l.UnitPrice));
    var order = Order.Draft(customer, lines);

    var rule = new OrderMinimumAmountRule(50m)
        .And(new CustomerVerifiedRule())
        .And(new CreditLimitRule());

    var validationResult = rule.ToResult(order);
    if (validationResult.IsFailure)
        return validationResult;

    order.Place();
    await _orders.AddAsync(order, cancellationToken);

    return Result.Success();
}

Now the handler is just orchestration, which is exactly what many DDD and CQRS guides recommend for the application layer. (Microsoft Learn)

One important DDD note

For a tutorial, putting the rule composition in the command handler is totally fine because it makes the pattern easy to see.

In a richer domain model, though, the most important invariants often belong inside the aggregate itself. Microsoft’s DDD guidance is very explicit here: aggregates are responsible for enforcing invariants across state changes, and application code should not become the real guardian of business consistency. (Microsoft Learn)

So a more domain-driven version could look like this:

public Result Place()
{
    var rule = new OrderMinimumAmountRule(50m)
        .And(new CustomerVerifiedRule())
        .And(new CreditLimitRule());

    if (!rule.IsSatisfiedBy(this))
        return Result.Failure(rule.ErrorMessage);

    Status = OrderStatus.Placed;
    return Result.Success();
}

Then the handler becomes:

public async Task<Result> Handle(PlaceOrderCommand command, CancellationToken cancellationToken)
{
    var customer = await _customers.GetByIdAsync(command.CustomerId, cancellationToken);
    if (customer is null)
        return Result.Failure("Customer not found.");

    var lines = command.Lines.Select(l => OrderLine.Create(l.ProductId, l.Quantity, l.UnitPrice));
    var order = Order.Draft(customer, lines);

    var result = order.Place();
    if (result.IsFailure)
        return result;

    await _orders.AddAsync(order, cancellationToken);
    return Result.Success();
}

This version is often closer to true DDD, because the order protects its own validity. (Microsoft Learn)

One honest limitation in the current implementation

Your example is great for teaching, but there is one thing worth mentioning in the article so readers do not copy it blindly.

Right now, AndRule.ErrorMessage always concatenates both messages:

public override string ErrorMessage =>
    _left.ErrorMessage + "; " + _right.ErrorMessage;

That means it can return messages for rules that actually passed.

And OrRule.ErrorMessage always returns the left message:

public override string ErrorMessage => _left.ErrorMessage;

So for production code, many teams move toward one of these options:

evaluate all broken rules and return a list
return a richer Result with structured errors
expose something like IReadOnlyList<string> GetErrors(T entity)

That kind of richer error modeling fits especially well with Result-based application flows. (Enterprise Craftsmanship)

A simple improvement could look like this:

public interface IRule<T>
{
    bool IsSatisfiedBy(T entity);
    IEnumerable<string> GetErrors(T entity);
}

But for a beginner-friendly tutorial, your current shape is still excellent because it keeps the idea small and easy to follow.

Final takeaway

The Rule pattern is a clean way to model business rules as reusable objects. Instead of burying domain knowledge inside scattered conditionals, you give each rule a name, a purpose, and a place in the model. When you add composition with AND, OR, and NOT, the code starts to read much closer to the business language itself. (martinfowler.com)

The Result pattern complements that perfectly. Rules decide whether an operation is allowed, while Results communicate whether the operation succeeded or failed in a clear and explicit way. Used together, they produce application code that is easier to read, easier to test, and much harder to misunderstand. (Enterprise Craftsmanship)

References

Martin Fowler, Specifications. (martinfowler.com)

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

Microsoft Learn, Implementing the microservice application layer using the Web API. (Microsoft Learn)

Microsoft Learn, Implementing a microservice domain model with .NET. (Microsoft Learn)

Vladimir Khorikov, Specification Pattern vs Always-Valid Domain Model. (Enterprise Craftsmanship)

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

Milan Jovanović, Functional Error Handling in .NET With the Result Pattern. (Milan Jovanović)

I can also turn this into a LinkedIn/dev.to version with a stronger hook and shorter paragraphs.

Building a Clean Master-Detail App with Blazor Server, MudBlazor, and EF Core

Spyros Ponaris — Thu, 26 Mar 2026 11:09:59 +0000

Building a Clean Master-Detail App with Blazor Server, MudBlazor, and EF Core

When building business applications, one of the most common requirements is a master-detail workflow. Orders and order items are a perfect example.

You need a clean list view, a reliable detail page, inline editing, validation, filtering, and a structure that can grow without becoming messy.

That is exactly what BlazorOrderApp is designed to demonstrate.

This application is a production-ready Blazor Server solution built with MudBlazor for the UI, EF Core with SQL Server for persistence, and a clean architecture that separates concerns across Domain, Application, Infrastructure, and Web layers.

Instead of placing everything in pages or code-behind files, the app keeps business rules, data access, validation, and UI responsibilities clearly divided.

At the core of the app is a classic master-detail pattern. The Orders.razor page acts as the master list, giving users filtering, search, pagination, and a structured overview of all orders. The OrderDetail.razor page handles the detail side, where users can inspect customer information, manage order items, and update order status in a focused way.

A big strength of this project is its use of the Repository and Specification patterns. The repository layer keeps EF Core logic centralized and testable, while specifications allow queries to be defined as reusable objects instead of scattered LINQ expressions. This makes filtering, paging, and retrieving complex data much easier to maintain over time.

Validation is handled with FluentValidation, which keeps rules explicit and easy to evolve as business needs grow. Combined with MudBlazor dialogs for create, edit, and delete operations, the result is a workflow that feels polished and user-friendly without sacrificing structure behind the scenes.

Overall, BlazorOrderApp is a strong example of how to build a modern internal business application in Blazor. It shows that you can create a clean, scalable CRUD system with a professional UI, solid architecture, and maintainable backend patterns, all within the .NET ecosystem.

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

Building a Blazor Form with the Command Pattern and Undo

Spyros Ponaris — Fri, 20 Mar 2026 08:39:06 +0000

Building a Blazor Form with the Command Pattern and Undo

In a typical Blazor form, inputs update the model directly. That is simple and works fine for basic CRUD screens, but it starts to feel limiting when you want more control over how changes happen, especially if you want undo support.

That is where the Command Pattern becomes useful.

Instead of letting the form change the model directly, each meaningful edit is wrapped inside a command object. That command is responsible for two things: applying the change and reversing it later if the user clicks Undo.

In other words, the form is no longer just changing values. It is recording actions.

The basic idea

In this approach, every field change becomes its own small object.

So if the user changes FirstName, that is one command.
If they change Email, that is another command.
If they toggle IsActive, that is a third command.

Those commands are stored in a stack, and Undo simply reverses the most recent one.

The core interface is very small:

public interface IUndoableCommand
{
    string Name { get; }
    void Execute();
    void Undo();
}

This keeps the pattern easy to understand. Every command knows what it does, and how to undo it.

The undo manager

To store the history of changes, we use a simple UndoManager:

public sealed class UndoManager
{
    private readonly Stack<IUndoableCommand> _undoStack = new();

    public bool CanUndo => _undoStack.Count > 0;

    public void Execute(IUndoableCommand command)
    {
        command.Execute();
        _undoStack.Push(command);
    }

    public void Undo()
    {
        if (_undoStack.Count == 0)
            return;

        var command = _undoStack.Pop();
        command.Undo();
    }

    public void Clear()
    {
        _undoStack.Clear();
    }
}

The idea is straightforward. When a command runs, it is pushed onto the stack. When the user clicks Undo, the last command is popped and reversed.

A reusable command for field changes

For a form, a generic SetPropertyCommand is often enough to get started.

public sealed class SetPropertyCommand<TModel, TValue> : IUndoableCommand
{
    private readonly TModel _model;
    private readonly Func<TModel, TValue> _getter;
    private readonly Action<TModel, TValue> _setter;
    private readonly TValue _newValue;

    private TValue? _oldValue;
    private bool _captured;

    public string Name { get; }

    public SetPropertyCommand(
        string name,
        TModel model,
        Func<TModel, TValue> getter,
        Action<TModel, TValue> setter,
        TValue newValue)
    {
        Name = name;
        _model = model;
        _getter = getter;
        _setter = setter;
        _newValue = newValue;
    }

    public void Execute()
    {
        if (!_captured)
        {
            _oldValue = _getter(_model);
            _captured = true;
        }

        _setter(_model, _newValue);
    }

    public void Undo()
    {
        if (!_captured)
            return;

        _setter(_model, _oldValue!);
    }
}

What makes this useful is that it does not permanently track the whole form. It only represents one change at a time.

That is an important distinction.

SetPropertyCommand is not a background tracker watching every field. It is more like a history entry. One command instance represents one action, like:

change FirstName from "Maria" to "Anna"

change Email from "old@mail.com" to "new@mail.com"

change IsActive from false to true

Example from the form

In the Blazor form, a field change is turned into a command like this:

ExecutePropertyCommand(
    "Change First Name",
    m => m.FirstName,
    (m, v) => m.FirstName = v,
    value ?? string.Empty,
    nameof(CustomerEditModel.FirstName));

This is a nice example because it shows exactly what the command needs:

how to read the property
how to set the property
what the new value is
which field changed

Then inside ExecutePropertyCommand, the actual command is created:

var command = new SetPropertyCommand<CustomerEditModel, TValue>(
    name,
    _model,
    getter,
    setter,
    newValue);

And then executed through the undo manager:

_undoManager.Execute(command);

Why this feels cleaner

This approach separates form editing from raw property assignment.

Without the pattern, a form usually does this:

_model.FirstName = value;

That works, but the change is gone the moment it happens. There is no history, no reversible action, and no good place to add undo logic later.

With the Command Pattern, the change becomes a first-class action. That makes the form behavior more predictable, easier to test, and easier to extend.

Why Save should stay separate

One important design choice is keeping Save outside the command stack.

Undo should reverse form edits, not database persistence.

That is why Save is better as a separate action:

private Task SaveAsync()
{
    ValidateModel();

    if (!_editContext.Validate())
        return Task.CompletedTask;

    // persist here

    _undoManager.Clear();
    RefreshPreview();

    return Task.CompletedTask;

This keeps responsibilities clear:

commands handle reversible UI changes

Save persists the current state

Trying to make Save itself a command usually creates confusion, because undoing a database write is a completely different problem.

A good fit for Blazor forms

This pattern is especially useful when a form has:

multiple editable fields
toggles or switches
add/remove actions
sections that can be reset
a real requirement for undo

The Command Pattern gives you a clean way to implement it without scattering logic all over the component.

Final thought

The most helpful way to think about this is not that the command is “tracking fields.” It is not.

What it is really doing is turning every meaningful edit into a small object that remembers what changed, so the form can step backward when needed.

That is what makes undo possible, and that is what makes the pattern useful in a Blazor form.

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

DEV Community: Spyros Ponaris

EF Core Mapping for DDD — for Dummies

1 · What's the Problem?

Bad model vs good model

Keep database stuff out of your business code

2 · Where Does the Code Go?

Folder layout

DbContext — only register the "boss" objects

3 · The Main Object (Aggregate Root)

The Order class — business rules inside

The mapping file — tells EF Core how to save Order

4 · Small Objects With No ID (Value Objects)

What a value object looks like

OwnsOne — save it as extra columns

ComplexType — even easier (.NET 8+)

OwnsMany — a list of small objects needs its own table

5 · Lists Inside an Object (Backing Fields)

Private list, public read-only view

OrderLine — belongs inside Order, not on its own

6 · Safe IDs (No More Guid Mix-ups)

Wrap your Guids

Tell EF Core how to save them

7 · The Mapping File (Putting It All Together)

What goes where?

8 · Saving, Loading & Mistakes to Avoid

How to load, change, and save

Domain events — memory only, not in the database

Quick lookup — "I have X, how do I map it?"

5 mistakes beginners make

What's next?

🚀 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

Prototype Design Pattern in C#: Cloning Objects Efficiently

Introduction

Understanding the Prototype Pattern

Structure

Prototype Pattern Example in C

Abstract Prototype

Explanation

Concrete Prototype: Ford

Explanation

Client Code

How the Program Works

Step 1: Create Prototype Objects

Step 2: Clone Instead of Creating

Step 3: Customize the Clone

Step 4: Repeat for Other Car Types

Understanding MemberwiseClone()

What Gets Copied?

Value Types

Reference Types

Shallow Copy vs Deep Copy

Shallow Copy

Deep Copy

Is MemberwiseClone() Safe?

Yes, when:

Be Careful When:

Benefits of the Prototype Pattern

1. Faster Object Creation

2. Reduces Repeated Initialization

3. Simplifies Object Creation

4. Supports Runtime Object Creation

Drawbacks

1. Deep Cloning Can Be Complex

2. Shared References Can Cause Bugs

3. Maintenance Overhead

When Should You Use the Prototype Pattern?

Conclusion

# Exploring a Practical Billing API Built with Modern .NET Patterns

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

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

Understanding `MemberwiseClone()`

Is `MemberwiseClone()` Safe?