DEV Community: Spyros Ponaris

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Spyros Ponaris — Mon, 12 Oct 2026 08:13:00 +0000

Moving from backend C# and enterprise patterns into native mobile development can feel like stepping into a whole new world. But after building my very first mobile app using Kotlin, the experience was a revelation—the syntax felt natural, the developer tooling was sharp, and the results were immediate.

Coming from a C# background, Kotlin doesn't feel foreign at all; it feels like an alternative timeline of modern object-oriented and functional programming.

Key Benefits That Stand Out for C# Developers

1. Built-in Null Safety

Just like C#'s nullable reference types, Kotlin barks at nullability at compile time rather than runtime. By explicitly distinguishing between nullable and non-nullable types using the ? operator, Kotlin nearly eliminates NullPointerException (the Java equivalent of NullReferenceException).

// Non-nullable string
var name: String = "Dev"

// Nullable string requiring safe-call
var nullableName: String? = null
val length = nullableName?.length ?: 0

2. Coroutines vs. Async/Await & Channels

If you are used to C#'s async/await pattern and System.Threading.Channels, Kotlin's coroutines feel instantly intuitive. They make non-blocking UI rendering, API fetching, and background processing clean, sequential, and structured.

// Asynchronous fetching without thread blocking
viewModelScope.launch {
    val result = repository.fetchData()
    _uiState.value = result
}

3. Radical Conciseness with Data Classes

Where a C# class or record requires multiple lines for properties and equality overrides, a Kotlin data class automatically generates equals(), hashCode(), and toString() methods in a single line.

data class UserProfile(val id: Int, val username: String, val email: String)

4. Native Extension Functions

Just like C# extension methods, Kotlin lets you add new functionality to existing classes without needing inheritance or wrapper patterns.

fun String.isValidEmail(): Boolean {
    return android.util.Patterns.EMAIL_ADDRESS.matcher(this).matches()
}

5. Modern Declarative UI (Jetpack Compose)

Paired with Jetpack Compose, Kotlin allows you to build declarative user interfaces—similar to modern web frameworks or XAML/MAUI—making responsive layouts for different screen sizes straightforward and maintainable.

Essential References for C# Developers

When diving deeper into Kotlin from .NET, these official specifications and guides are worth bookmarking:

Kotlin Standard Library API (kotlin-stdlib): Core data structures, scope functions (let, apply, also, run), and collections.
Kotlin Language Specification: Standard compiler behaviors, type inference, subtyping rules, and generics.
Kotlin Coroutines Guide: Official reference for structured concurrency, flows, and channels.
Android Jetpack Compose Documentation: Declarative UI toolkit for native Android app development.

The Takeaway

Building that first mobile app proves that backend principles—clean architecture, strong typing, and asynchronous design—translate directly into mobile software engineering. Kotlin bridges the gap perfectly, giving C# developers a powerful and highly productive stack for building native Android applications.

Building a Dynamic Strategy Pattern in C# with Customer Tiers and Plugin Architecture

Spyros Ponaris — Fri, 02 Oct 2026 09:07:13 +0000

The Strategy Pattern is a staple of object-oriented design. It lets you encapsulate a family of algorithms and make them interchangeable at runtime. However, traditional implementations often suffer from heavy interface hierarchies and rigid factory logic.

In modern C#, language features like switch expressions, primary constructors, collection expressions, and collectible AssemblyLoadContext allow us to build clean, extensible strategy pipelines with zero unnecessary boilerplate.

In this article, we'll walk through building a flexible shipping rate calculator that supports:

Multiple Carrier Strategies (DHL, FedEx, UPS).
Customer Tier Rules (VIP, Corporate, Standard) via pattern matching.
Dynamic Plugin Architecture to load new strategies from external .dll files without recompiling.
Zero-Allocation Execution for performance-critical hot paths.

You can find the complete source code on GitHub: stevsharp/Shipping-strategy-demo.

1. Domain Contracts & Core Models

We start by defining clean, immutable records for our domain model and a clear IShippingStrategy interface.

namespace Shipping.Contracts;

public enum CustomerType { Standard, Vip, Corporate }

public record Customer(string Id, string Name, CustomerType Type, int LoyaltyPoints);

public record Order(string OrderId, decimal Subtotal, decimal WeightKg, Customer Customer);

public interface IShippingStrategy
{
    string ProviderName { get; }
    decimal CalculateCost(Order order);
}

2. Encapsulating Carrier Strategies with Pattern Matching

Each strategy encapsulates carrier-specific pricing. Instead of cluttering our algorithms with if/else checks for customer ranks, we leverage C# switch expressions over the Customer object.

DHL Express Strategy

public class DhlShippingStrategy : IShippingStrategy
{
    public string ProviderName => "DHL Express";

    public decimal CalculateCost(Order order)
    {
        // DHL Base International Rate
        decimal baseRate = 25.00m + (order.WeightKg * 3.50m);

        return order.Customer switch
        {
            // VIPs get priority express at a 40% discount
            { Type: CustomerType.Vip } => baseRate * 0.60m,

            // Corporate accounts get a flat $15 discount
            { Type: CustomerType.Corporate } => Math.Max(5.00m, baseRate - 15.00m),

            // Standard customers with high loyalty points get $5 off
            { LoyaltyPoints: > 500 } => baseRate - 5.00m,

            _ => baseRate
        };
    }
}

FedEx & UPS Implementations

public class FedExShippingStrategy : IShippingStrategy
{
    public string ProviderName => "FedEx";

    public decimal CalculateCost(Order order)
    {
        decimal baseRate = 15.00m + (order.WeightKg * 2.50m);

        return order.Customer switch
        {
            { Type: CustomerType.Vip } => baseRate * 0.50m,
            { Type: CustomerType.Corporate } => baseRate * 0.80m,
            _ => baseRate
        };
    }
}

public class UpsShippingStrategy : IShippingStrategy
{
    public string ProviderName => "UPS Ground";

    public decimal CalculateCost(Order order)
    {
        decimal baseRate = 12.00m + (order.WeightKg * 2.00m);

        return order.Customer switch
        {
            { Type: CustomerType.Vip } => baseRate * 0.70m,
            _ => baseRate
        };
    }
}

3. Dynamic Strategy Factory & Plugin Loader

To keep our host application fully compliant with the Open/Closed Principle, we combine our strategies with a factory capable of scanning an external /plugins directory and instantiating .dll strategies at runtime using AssemblyLoadContext.

using System.Reflection;
using System.Runtime.Loader;
using Shipping.Contracts;

public class ShippingStrategyFactory
{
    private readonly Dictionary<string, IShippingStrategy> _strategies = new(StringComparer.OrdinalIgnoreCase);

    public ShippingStrategyFactory()
    {
        // Register built-in strategies
        Register(new DhlShippingStrategy());
        Register(new FedExShippingStrategy());
        Register(new UpsShippingStrategy());
    }

    public void Register(IShippingStrategy strategy)
    {
        _strategies[strategy.ProviderName] = strategy;
    }

    public IShippingStrategy GetStrategy(string providerKey)
    {
        return _strategies.GetValueOrDefault(providerKey)
            ?? throw new NotSupportedException($"Shipping provider '{providerKey}' is not supported.");
    }

    /// <summary>
    /// Scans a folder for external strategy DLLs and registers them dynamically.
    /// </summary>
    public void LoadExternalPlugins(string pluginsFolderPath)
    {
        if (!Directory.Exists(pluginsFolderPath)) return;

        foreach (string dllPath in Directory.GetFiles(pluginsFolderPath, "*.dll"))
        {
            var loadContext = new AssemblyLoadContext(dllPath, isCollectible: true);
            Assembly assembly = loadContext.LoadFromAssemblyPath(dllPath);

            foreach (Type type in assembly.GetTypes())
            {
                if (typeof(IShippingStrategy).IsAssignableFrom(type) && !type.IsAbstract && !type.IsInterface)
                {
                    if (Activator.CreateInstance(type) is IShippingStrategy pluginStrategy)
                    {
                        Register(pluginStrategy);
                        Console.WriteLine($"[Plugin Loaded]: {pluginStrategy.ProviderName}");
                    }
                }
            }
        }
    }

    public IEnumerable<string> AvailableProviders => _strategies.Keys;
}

4. Zero-Allocation Hot-Path Variant

In high-throughput microservices or financial engines, object allocations add GC pressure. For those hot paths, you can express the strategy directly using a stack-allocated readonly ref struct:

public readonly ref struct FastPricingContext
{
    public required decimal Subtotal { get; init; }
    public required Customer Customer { get; init; }
}

public static class FastPricingStrategy
{
    public static decimal Calculate(in FastPricingContext ctx) => ctx switch
    {
        { Customer.Type: CustomerType.Vip, Subtotal: > 500m } => ctx.Subtotal * 0.70m,
        { Customer.Type: CustomerType.Vip }                  => ctx.Subtotal * 0.80m,
        { Customer.Type: CustomerType.Corporate }            => ctx.Subtotal * 0.85m,
        _                                                    => ctx.Subtotal
    };
}

5. Putting It All Together

public static class Program
{
    public static void Main()
    {
        var vipCustomer = new Customer("C-101", "Alice", CustomerType.Vip, LoyaltyPoints: 1200);
        var order = new Order("ORD-9901", Subtotal: 200.00m, WeightKg: 4.5m, Customer: vipCustomer);

        var factory = new ShippingStrategyFactory();

        // Resolve and calculate using DHL Strategy
        IShippingStrategy dhl = factory.GetStrategy("DHL Express");
        decimal dhlCost = dhl.CalculateCost(order);
        Console.WriteLine($"[DHL Express] Final Cost: ${dhlCost:F2}");

        // Resolve and calculate using FedEx Strategy
        IShippingStrategy fedEx = factory.GetStrategy("FedEx");
        decimal fedExCost = fedEx.CalculateCost(order);
        Console.WriteLine($"[FedEx]       Final Cost: ${fedExCost:F2}");
    }
}

Summary Matrix

Technique	Primary Advantage	Memory Overhead	Use Case
Context Strategy Class	Highly readable, unit-testable	Standard heap allocations	Typical enterprise logic
Plugin Factory (`DLL`)	Hot-swappable providers without re-compiling	Low assembly metadata cost	Extensible SaaS / Monoliths
`ref struct` Strategy	Zero heap allocations	Zero GC cost	High-frequency / Game engines

References & Further Reading

📁 Source Code Repository: stevsharp/Shipping-strategy-demo on GitHub
📖 Microsoft Docs: Pattern matching in C#
📖 Microsoft Docs: AssemblyLoadContext in .NET
📘 Refactoring Guru: Strategy Design Pattern Overview

Stop Hardcoding Business Rules: Building a Dynamic Workflow Engine in C#

Spyros Ponaris — Tue, 01 Sep 2026 14:49:47 +0000

Every growing C# application eventually hits a wall: business logic becomes a tangle of deeply nested if/else checks scattered across service layers. Every time marketing tweaks a promotion or compliance updates an age restriction, developers have to modify compiled C#, run regression tests, and push a new deployment.

What if your code handled the execution flow while your database controlled the rules?

By combining the Chain of Responsibility pattern, Keyed Dependency Injection, and Microsoft’s open-source `RulesEngine`, you can build a flexible pipeline that evaluates dynamic business rules on the fly.

The Architecture: Code vs. Configuration

To keep systems maintainable, separate procedural execution (what your system does) from business constraints (what your system allows):

[ Incoming Request ]
         │
         ▼
[ Dynamic Workflow Engine ]
         │
         ├── 1. Fetch Steps & JSON Rules from Database
         │
         ├── 2. Evaluate Dynamic Rules (Microsoft.RulesEngine)
         │        ├── Passed ──► Proceed
         │        └── Failed ──► Abort & Return Reason
         │
         └── 3. Execute Step Handler (via Keyed DI)

Chain of Responsibility: Keeps each processing step (Inventory, Payment, Shipping) modular and isolated.
Microsoft RulesEngine: Parses readable expression strings (like Amount > 5000 && CreditScore < 700) stored as JSON in your database and evaluates them against your C# objects at runtime.

1. Defining the Workflow Context

First, create a state object passed down the execution chain. This context carries order details and tracks pipeline status.

public class OrderContext
{
    public string OrderId { get; set; } = string.Empty;
    public decimal Amount { get; set; }
    public int CustomerAge { get; set; }
    public int CreditScore { get; set; }

    public bool IsAborted { get; private set; }
    public string AbortReason { get; private set; } = string.Empty;

    public void Abort(string reason)
    {
        IsAborted = true;
        AbortReason = reason;
    }
}

2. Setting Up Dynamic Rules in JSON

Instead of writing hardcoded conditions in C#, store rules as JSON objects—either in SQL tables, a NoSQL store, or configuration files.

[
  {
    "WorkflowName": "PaymentRules",
    "Rules": [
      {
        "RuleName": "HighValueCreditCheck",
        "ErrorMessage": "Orders over $5,000 require a Credit Score of at least 700.",
        "Expression": "Amount <= 5000 || CreditScore >= 700"
      }
    ]
  }
]

3. Building the Pipeline Engine

Using .NET 8/9 Keyed Services, handlers are resolved dynamically using string keys fetched from your database schema.

public interface IWorkflowHandler
{
    Task HandleAsync(OrderContext context, Func<Task> next);
}

public class DynamicWorkflowEngine
{
    private readonly IServiceProvider _serviceProvider;

    public DynamicWorkflowEngine(IServiceProvider serviceProvider) => _serviceProvider = serviceProvider;

    public async Task ExecuteAsync(OrderContext context, List<DbWorkflowStep> steps)
    {
        foreach (var step in steps)
        {
            if (context.IsAborted) break;

            // Step 1: Evaluate DB-stored Rules
            if (!string.IsNullOrWhiteSpace(step.StepRulesJson))
            {
                var workflowList = JsonConvert.DeserializeObject<List<WorkflowRules>>(step.StepRulesJson);
                var re = new RulesEngine.RulesEngine(workflowList.ToArray());

                var results = await re.ExecuteAllRulesAsync(workflowList[0].WorkflowName, context);

                if (results.Any(r => !r.IsSuccess))
                {
                    var failedRule = results.First(r => !r.IsSuccess);
                    context.Abort($"Rule failed at {step.HandlerKey}: {failedRule.Rule.ErrorMessage}");
                    break;
                }
            }

            // Step 2: Execute Handler from DI
            var handler = _serviceProvider.GetKeyedService<IWorkflowHandler>(step.HandlerKey);
            if (handler != null)
            {
                await handler.HandleAsync(context, () => Task.CompletedTask);
            }
        }
    }
}

Why This Pattern Wins

Zero-Downtime Rule Updates: Non-developers or admin dashboards can edit business expressions in the database. Updated rules apply instantly without recompiling C#.
Auditable Failure Reasons: RulesEngine explicitly reports which rule failed and why, giving clear feedback to users and log aggregators.
Expression Safety: Unlike executing raw string scripts, RulesEngine safely compiles expressions into Abstract Syntax Trees (ASTs), avoiding code injection vulnerabilities.

Production Tip: Performance

Evaluating JSON rules introduces lightweight parsing overhead. In production, wrap DB calls and RulesEngine instances in an IMemoryCache. Invalidate the cache only when an administrator updates a rule in your database.

By shifting fast-changing business rules into dynamic configuration, your codebase stays lean, maintainable, and resilient to change.

Source code :

https://github.com/stevsharp/DynamicWorkflowConsole

Getting Started with GraphQL in ASP.NET

Spyros Ponaris — Tue, 04 Aug 2026 08:47:40 +0000

Getting Started with GraphQL in ASP.NET and EF Core

GraphQL is a modern API technology that allows clients to request exactly the data they need. Unlike traditional REST APIs, GraphQL uses a single endpoint and gives consumers more control over the response structure.

If you're building ASP.NET applications with Entity Framework Core, adding GraphQL can be a great way to expose your data efficiently.

Why GraphQL?

With REST APIs, clients often receive more data than they need or must call multiple endpoints to collect related information.

GraphQL helps solve these problems by providing:

Flexible data retrieval
Fewer API requests
Strongly typed schemas
Better performance for complex data scenarios

Create a New ASP.NET Project

Start by creating a Web API project:

dotnet new webapi -n GraphQLDemo
cd GraphQLDemo

Install the required packages:

dotnet add package HotChocolate.AspNetCore
dotnet add package HotChocolate.Data.EntityFramework
dotnet add package Microsoft.EntityFrameworkCore.InMemory

Create the Entity

Let's create a simple Product model:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

Configure EF Core

Create a DbContext:

using Microsoft.EntityFrameworkCore;

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options)
    {
    }

    public DbSet<Product> Products => Set<Product>();
}

Create a GraphQL Query

GraphQL queries define the data clients can request.

public class Query
{
    public IQueryable<Product> GetProducts(
        [Service] AppDbContext context)
    {
        return context.Products;
    }
}

Returning IQueryable allows Hot Chocolate to optimize filtering, sorting, and projections.

In Program.cs:

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseInMemoryDatabase("ProductsDb"));

builder.Services
    .AddGraphQLServer()
    .AddQueryType<Query>();

var app = builder.Build();

using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    db.Products.AddRange(
        new Product { Id = 1, Name = "Laptop", Price = 999.99m },
        new Product { Id = 2, Name = "Mouse", Price = 29.99m }
    );

    db.SaveChanges();
}

app.MapGraphQL();

app.Run();

Run Your First Query

Navigate to:

https://localhost:5001/graphql

Execute:

query {
  products {
    id
    name
    price
  }
}

Response:

{
  "data": {
    "products": [
      {
        "id": 1,
        "name": "Laptop",
        "price": 999.99
      },
      {
        "id": 2,
        "name": "Mouse",
        "price": 29.99
      }
    ]
  }
}

Enable Filtering and Sorting

One of the best features of Hot Chocolate is built-in filtering and sorting.

Update the query:

using HotChocolate.Data;

public class Query
{
    [UseFiltering]
    [UseSorting]
    public IQueryable<Product> GetProducts(
        [Service] AppDbContext context)
    {
        return context.Products;
    }
}

builder.Services
    .AddGraphQLServer()
    .AddQueryType<Query>()
    .AddFiltering()
    .AddSorting();

Now clients can run queries like:

query {
  products(
    where: { price: { gt: 100 } }
    order: { price: DESC }
  ) {
    name
    price
  }
}

Conclusion

GraphQL and EF Core work very well together in ASP.NET applications. With Hot Chocolate, you can expose database entities through GraphQL with minimal configuration while gaining powerful features like filtering, sorting, and projections.

If you're already using EF Core, adding GraphQL is an easy way to make your APIs more flexible and developer-friendly. Start with simple queries, then move on to mutations, authentication, and real database providers like SQL Server or PostgreSQL.

Happy coding! 🚀

References

GraphQL Official Documentation, Learn GraphQL https://graphql.org/learn/
GraphQL Official Documentation, Queries https://graphql.org/learn/queries/
Hot Chocolate Documentation, Getting Started with GraphQL in .NET https://chillicream.com/docs/hotchocolate/get-started-with-graphql-in-net-core
- Hot Chocolate Documentation, GraphQL Server for .NET https://chillicream.com/docs/hotchocolate

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.

DEV Community: Spyros Ponaris

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Coming from a C# background, Kotlin doesn't feel foreign at all; it feels like an alternative timeline of modern object-oriented and functional programming.

Key Benefits That Stand Out for C# Developers

1. Built-in Null Safety

2. Coroutines vs. Async/Await & Channels

3. Radical Conciseness with Data Classes

4. Native Extension Functions

5. Modern Declarative UI (Jetpack Compose)

Essential References for C# Developers

The Takeaway

Building a Dynamic Strategy Pattern in C# with Customer Tiers and Plugin Architecture

1. Domain Contracts & Core Models

2. Encapsulating Carrier Strategies with Pattern Matching

DHL Express Strategy

FedEx & UPS Implementations

3. Dynamic Strategy Factory & Plugin Loader

4. Zero-Allocation Hot-Path Variant

5. Putting It All Together

Summary Matrix

References & Further Reading

Stop Hardcoding Business Rules: Building a Dynamic Workflow Engine in C#

The Architecture: Code vs. Configuration

1. Defining the Workflow Context

2. Setting Up Dynamic Rules in JSON

3. Building the Pipeline Engine

Why This Pattern Wins

Production Tip: Performance

Getting Started with GraphQL in ASP.NET

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

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

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

Understanding `MemberwiseClone()`

Is `MemberwiseClone()` Safe?