We know that every Entity Framework Core (EF Core) LINQ query has a corresponding SQL query. That equivalent SQL is actually executed under the hood. Some LINQ expressions involve. NET-specific code, such as calling a method, using a reflection filter, or accessing files. You may have found several code blocks of your query that could not be translated. Why does it happen? In today's post, I will cover the reasons along with on-ground examples.

LINQ Queries Translation

We will write different LINQ queries in a real project and examine what results they yield. I will use a Console application with a PostgreSQL database as an example.

Step 1: Create a project

dotnet new console -n EfTranslationDemo
cd EfTranslationDemo

Step 2: Install NuGet packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

Step 3: Model for the table

This will be a single-table application consisting of the Perfume model.

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

    public string Name { get; set; } = string.Empty;

    public string Brand { get; set; } = string.Empty;

    public decimal Price { get; set; }

    public int Rating { get; set; }

    public DateTime ReleaseDate { get; set; }
}

Step 4: Create a database

To speed up the process, I have already created the database and the Perfumes table.

CREATE DATABASE perfumedb;

CREATE TABLE public."Perfumes" (
    "Id" serial PRIMARY KEY,
    "Name" varchar(255) NOT NULL DEFAULT '',
    "Brand" varchar(255) NOT NULL DEFAULT '',
    "Price" decimal(10,2) NOT NULL,
    "Rating" integer NOT NULL,
    "ReleaseDate" timestamp NOT NULL DEFAULT (NOW() AT TIME ZONE 'UTC')
);

Step 5: Set up the DB context

using EfTranslationDemo.Models;
using Microsoft.EntityFrameworkCore;

namespace EfTranslationDemo.Data;

public class ApplicationDbContext: DbContext
{
    public DbSet<Perfume> Perfumes => Set<Perfume>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options
            .UseNpgsql("Your Connection string with db name perfumedb")
            .LogTo(Console.WriteLine);
    }
}

Step 6: Seed data

To begin with, I will seed some data programmatically.

using EfTranslationDemo.Data;
using EfTranslationDemo.Models;
using Microsoft.EntityFrameworkCore;

using var context = new ApplicationDbContext();

context.Database.EnsureCreated();

SeedData(context);

static void SeedData(ApplicationDbContext context)
{
    if (context.Perfumes.Any())
        return;

    context.Perfumes.AddRange(
        new Perfume { Name="Sauvage", Brand="Dior", Price=120, Rating=9, ReleaseDate=new DateTime(2018,1,1,0,0,0, DateTimeKind.Utc)},
        new Perfume { Name="Bleu De Chanel", Brand="Chanel", Price=150, Rating=10, ReleaseDate=new DateTime(2017,1,1,0,0,0, DateTimeKind.Utc)},
        new Perfume { Name="Aventus", Brand="Creed", Price=300, Rating=10, ReleaseDate=new DateTime(2015,1,1,0,0,0, DateTimeKind.Utc)},
        new Perfume { Name="F Black", Brand="Ferragamo", Price=60, Rating=7, ReleaseDate=new DateTime(2019,1,1,0,0,0, DateTimeKind.Utc)}
    );

    context.SaveChanges();
}

Fast forward, the data is seeded to the database

Step 7: LINQ queries testing

1. Query with price filter

A simple query to fetch perfumes with a price of more than 100.

Console.WriteLine("Full translable");
var query1 = context
    .Perfumes
    .Where(p => p.Price > 100)
    .Select(p => new { p.Name, p.Price });

Console.WriteLine(query1.ToQueryString());

2. Filter with Name

We will filter the data with the name starting with 'B'.

var query2 = context
    .Perfumes
    .Where(p => p.Name.StartsWith("B"));

Console.WriteLine(query2.ToQueryString());

StartsWith() translates to SQL's LIKE . Similarly, EndsWith and Contains are also translated.

3. Client Side Execution

Another translatable but performance-heavy solution is

var perfumes = context
    .Perfumes
    .ToList()
    .Where(p => p.Price > 100);

Console.WriteLine(perfumes.Count());

It loads all the data in memory first, then applies a filter on the stored data. Such a solution can cause significant problems, especially when the data is large.

4. External list filter

We can write a translatable filter with an external list

var brands = new List<string> { "Dior", "Creed" };

var query = context
    .Perfumes
    .Where(p => brands.Contains(p.Brand));

Console.WriteLine(query.ToQueryString());

EF Core converts the C# in-memory list into SQL constants.

5. DateTime filter

Any filter with parsing datetime will work the same as any other.

var query = context
    .Perfumes
    .Where(p => p.ReleaseDate.Year > 2016);

Console.WriteLine(query.ToQueryString());

Common DateTime properties are supported.

6. Custom method filter

What you cannot do in a LINQ query is to filter by a method. LINQ can't find an SQL equivalent of it.

static bool IsLuxury(Perfume perfume)
{
    return perfume.Price > 200;
}

var query = context
    .Perfumes
    .Where(p => IsLuxury(p));

Console.WriteLine(query.ToQueryString());

EF Core cannot inspect the body of arbitrary C# methods.

7. Regex matching

We can simply put a regex pattern in the filter as well.

var query = context
    .Perfumes
    .Where(p => Regex.IsMatch(p.Name, "^A"));

Console.WriteLine(query.ToQueryString());

var result = query.ToList();
Console.WriteLine(result.Count());

8. Non-Translatable Projection

string GetCategory(decimal price)
{
    return price > 150 ? "Luxury" : "Regular";
}

var query = context
    .Perfumes
    .Select(p => new
    {
        p.Name,
        Category = GetCategory(p.Price)
    });

Console.WriteLine(query.ToQueryString());

The right way

var query = context
    .Perfumes
    .Select(p => new
    {
        p.Name,
        Category = p.Price > 150 ? "Luxury" : "Regular"
    });

Console.WriteLine(query.ToQueryString());

9. Reflection

.NET does not have an equivalent in SQL.

var query = context
    .Perfumes
    .Where(p => p.GetType().GetProperty("Price") != null);

Console.WriteLine(query.ToQueryString());

10. File System Access

var query = context
    .Perfumes
    .Where(p => File.Exists($"brands/{p.Brand}.txt"));

Console.WriteLine(query.ToQueryString());

11. Random number generation

var query = context
    .Perfumes
    .Where(p => Random.Shared.Next(0, 10) > 5);

Console.WriteLine(query.ToQueryString());

A filter using random number generation did not translate.

12. string.Compare method

One of the cool methods that we often use for string comparison is string.Comparison. Unfortunately, you cannot use it in a LINQ query.

var query = context
    .Perfumes
    .Where(p => 
        string.Compare(p.Name, "Sauvage", 
            StringComparison.OrdinalIgnoreCase) == 0
        );
var result  = await query.ToListAsync();
Console.WriteLine(query.ToQueryString());

Why does EF Core have limitations in translating LINQ queries?

One question arises that even after years of improvement and enhancement, EF Core does not translate some common C# expressions in LINQ. Actually, LINQ does not merely read and execute any query. It first creates an expression tree of the query. Next, these trees are converted to SQL. SQL queries are a declarative language that describes what data you want, not how to compute it step by step. So, methods' bodies are not parsed, as in our case with the IsLuxury method, where expressions do not analyze arbitrary method bodies for translation. Also, C# is a full programming language, whereas SQL lacks many of the features of a programming language. Neither can it read its logic, as SQL servers cannot execute .NET runtime code.

EF Core is responsible for translating an expression tree to database-specific SQL. We know that every database has its own SQL dialect. For example, DATE_PART('year', column) in a PostgreSQL expression, while the SQL Server equivalent is YEAR(column). So EF must maintain different translators for each database. It does not rely on a single translator, so there are limitations in translating each and every query across diverse database providers. Finally, some .NET runtime features are specific to the program, such as random number generation, ordinal string comparison, and reflection, which are impossible to translate.

Conclusion

EF Core is a popular ORM and the default choice for many developers for database operations. EF Core uses LINQ for querying and enables you to use databases as if they were in C#. However, the underlying database cannot fully replicate a complete programming language like C#. Many programming expressions and filtering logic cannot be translated into a database query. Calling a method in a LINQ query, using reflection, and ordinal string comparison are examples of limitations in EF Core. SQL is specifically designed to fetch data and is not a programming language. It does not have the .NET runtime, so it cannot execute .NET features. In this post, I have gone through many examples that can be translated into SQL and some common queries that cannot.

Code: https://github.com/elmahio-blog/EfTranslationDemo.git

Entity Framework Core (EF Core) is working fine in your project. But the moment you use views, the migration gets messy. As a developer, I know any problem in the migration is haunting. You have to update and take care of other migrations so they don't get disturbed. If not done well, database views can throw you into a pitfall. In today's post, I will walk through how to map views in EF Core without breaking migrations.

What is a database view?

A view is a named query that acts as a virtual table. It is defined using base tables or previously defined views and provides an abstraction of a complex query. Views do not store any data, but they execute the enclosed query. Views reduce client-side code by encapsulating logic and adding reusability. Although it supports data modifications like create and update in some cases, it is primarily used for read-only operations.

Mapping database views with EF Core

Let's see, with the glasses from the actual project, how we can utilize views. I will use a console project with a PostgreSQL database.

Step 1: Create the project

dotnet new console -n EfCoreViewDemo
cd EfCoreViewDemo

Step 2: Install necessary NuGet packages

dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.Extensions.Configuration
dotnet add package Microsoft.Extensions.Configuration.Json

Configuration packages will be used to load appsettings.

Step 3: Create appsettings.json

Adding appsettings.json with a database connection string.

{
  "ConnectionStrings": {
    "PostgresConnection": "Host=localhost;Port=5432;Database=productVDb;Username=postgres;Password=1234"
  }
}

Step 4: Define Models

Add the Product class:

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

The ProductSummary class will catch the results of the view:

namespace EfCoreViewDemo.Models;

public class ProductSummary
{
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

Step 5: Configure DbContext

using EfCoreViewDemo.Models;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;

namespace EfCoreViewDemo.Data;

public class ApplicationDbContext: DbContext
{
    public DbSet<Product> Products => Set<Product>();
    public DbSet<ProductSummary> ProductSummaries => Set<ProductSummary>();

    private readonly string _connectionString;

    public ApplicationDbContext()
    {
        var config = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("appsettings.json")
            .Build();

        _connectionString = config.GetConnectionString("PostgresConnection");
    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseNpgsql(_connectionString);
    }
    
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<ProductSummary>()
            .ToView("vw_product_summary")   
            .HasNoKey();                  
    }
}

One important configuration is ToView(...) that specifies the DbSet map as a database view. Calling ProductSummaries will fetch data from the view named vw_product_summary. HasNoKey() specifies that views are read-only structures in the database and do not contain any primary key. If not specified, EF Core expects a primary key on the entity and throws an exception.

Step 6:  Set up appsettings.json in the project

By default, a console app will expect the file in the bin directory. To read newly added appsettings from the root directory, add the following inside the <Project> tag of the application's project file:

<ItemGroup>
  <None Update="appsettings.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

Step 7: Run migrations

dotnet ef migrations add InitialCreate

So the migration will look like

using Microsoft.EntityFrameworkCore.Migrations;
using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata;

#nullable disable

namespace EfCoreViewDemo.Migrations
{
    /// <inheritdoc />
    public partial class InitialCreate : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.CreateTable(
                name: "Products",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false)
                        .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Price = table.Column<decimal>(type: "numeric", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Products", x => x.Id);
                });            
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.DropTable(
                name: "Products");
        }
    }
}

But we skipped views from EF Core's tracking, so we need to add it manually in the Up method.

migrationBuilder.Sql(@"
  CREATE VIEW vw_product_summary AS
  SELECT ""Name"", ""Price""
  FROM ""Products"";
");

While in the Down method:

migrationBuilder
    .Sql(@"DROP VIEW IF EXISTS vw_product_summary;");

To reflect the migration

dotnet ef database update

Now, the database looks like

Step 8: Define program

using EfCoreViewDemo.Data;
using EfCoreViewDemo.Models;

using var context = new ApplicationDbContext();

context.Products.Add(new Product { Name = "Laptop", Price = 1000 });
context.Products.Add(new Product { Name = "Keyboard", Price = 100 });
context.Products.Add(new Product { Name = "Headphone", Price = 150 });
context.Products.Add(new Product { Name = "Web cam", Price = 200 });
context.Products.Add(new Product { Name = "Mouse", Price = 50 });

context.SaveChanges();

var summaries = context.ProductSummaries.ToList();

foreach (var item in summaries)
{
    Console.WriteLine($"{item.Name} - {item.Price}");
}

To summarize, I added 5 records manually. Later, I am calling ProductSummaries, which is a view.

Step 9: Run the project

Manual migration allows you to automate view definition without breaking migration functionality. A naive approach is to write views directly in the database.

Step 10: Update the view

Let's say a requirement came, and we need to update the view.

Create an empty migration:

dotnet ef migrations add UpdateProductSummaryView

Manual query in migration will look like this:

using Microsoft.EntityFrameworkCore.Migrations;

#nullable disable

namespace EfCoreViewDemo.Migrations
{
    /// <inheritdoc />
    public partial class UpdateProductSummaryView : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql(@"
                DROP VIEW IF EXISTS vw_product_summary;

                CREATE VIEW vw_product_summary AS
                SELECT ""Name"", ""Price"", ""Price"" * 0.9 AS ""DiscountedPrice""
                FROM ""Products"";
            ");
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql(@"
                DROP VIEW IF EXISTS vw_product_summary;

                CREATE VIEW vw_product_summary AS
                SELECT ""Name"", ""Price""
                FROM ""Products"";
            ");
        }
    }
}

Updating the model accordingly:

namespace EfCoreViewDemo.Models;

public class ProductSummary
{
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public decimal DiscountedPrice { get; set; }
}

In Program.cs, the view call will become:

var summaries = context.ProductSummaries.ToList();

foreach (var item in summaries)
{
    Console.WriteLine($"{item.Name} - {item.Price} - {item.DiscountedPrice}");
}

Hence, the result

Conclusion

Database Views are great for enclosing complex logic as virtual tables. Developers often use it extensively in the application. However, views can make EF Core migration tracking tedious if not managed properly. I provided a solution in today's blog on how you can design views without harming migration.

Code: https://github.com/elmahio-blog/EfCoreViewDemo.git

What really happens when you write throw new Exception() in .NET? Microsoft guidelines state that

When a member throws an exception, its performance can be orders of magnitude slower. 

It's not just a simple jump to a catch block, but a lot goes in CLR (Common Language Runtime). Expensive operations such as stack trace capture, heap allocations, and method unwinding occur each time. You will not want to use them in any hot paths. Today, In today's post, I will help you decide when exceptions are appropriate and when a simple alternative type might be better.

What is an Exception?

An exception is an error condition or unexpected behaviour during the execution of a program. Exceptions can occur at runtime for various reasons, such as accessing a null object, dividing by zero, or requesting a file that is not found. A C# exception contains several properties, including a Message describing the cause of the exception. StackTrace contains the sequence of method calls that led to the exception in reverse call order to trace the exception source.

How does an exception work?

The try block encloses the code prone to exceptions. try/catch protects the application from blowing up. Use the throw keyword to signal the error and throw an Exception object containing detailed information, such as a message and a stack trace. The caught exception allows the program to continue gracefully and notify the user where and what error occurred. When an error occurs, the CLR searches for a compatible catch block in the current method. If not found, it moves up the call stack to the calling method, and so on. Once a matching catch is found based on the exception type, control jumps to that block. In an unhandled exception situation where no compatible catch block is found, the application can terminate. Exception handling uses a heap to store the message. To look for a catch body, the CLR unwinds the stack by removing intermediate stack frames. The JIT must generate EH tables and add hidden control-flow metadata.

What is OneOf<T> in .NET?

OneOf<T> or OneOf<T1, T2, T...> represents a discriminated union containing all possible returns of an operation or a method. It contains an array of types, allowing a method to return one of several defined possibilities. The OneOf pattern provides you with fine-grained control and type safety.

Examine Exceptions with the benchmark.

To truly understand it, let's create an application. I will use a console application.

Step 1: Create the project

dotnet new console -n ExceptionBenchmark
cd ExceptionBenchmark

Step 2: Add necessary packages

I am adding the Benchmark library along with OneOf, which is used for the OneOf return type.

dotnet add package BenchmarkDotNet
dotnet add package OneOf

Step 3: Set up the program.cs

All the code is in the Program.cs

using System;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using OneOf;

BenchmarkRunner.Run<ExceptionBenchmarks>();

[MemoryDiagnoser] 
public class ExceptionBenchmarks
{
    private const int Iterations = 100_000;
    private const int FailureEvery = 10;

    [Benchmark]
    public int NoException()
    {
        int failures = 0;

        for (int i = 1; i <= Iterations; i++)
        {
            if (!DoWork_NoException(i))
                failures++;
        }

        return failures;
    }

    private bool DoWork_NoException(int i)
    {
        return i % FailureEvery != 0;
    }

    [Benchmark]
    public int WithException()
    {
        int failures = 0;

        for (int i = 1; i <= Iterations; i++)
        {
            try
            {
                DoWork_WithException(i);
            }
            catch
            {
                failures++;
            }
        }

        return failures;
    }

    private void DoWork_WithException(int i)
    {
        if (i % FailureEvery == 0)
            throw new InvalidOperationException();
    }

    [Benchmark]
    public int WithOneOf()
    {
        int failures = 0;

        for (int i = 1; i <= Iterations; i++)
        {
            var result = DoWork_WithOneOf(i);

            if (result.IsT1)
                failures++;
        }

        return failures;
    }

    private OneOf<Success, Error> DoWork_WithOneOf(int i)
    {
        if (i % FailureEvery == 0)
            return new Error("Error");

        return new Success("Passed");
    }

    private readonly struct Success
    {
        public string Message { get; }

        public Success(string message)
        {
            Message = message;
        }
    }

    private readonly struct Error
    {
        public string Message { get; }

        public Error(string message)
        {
            Message = message;
        }
    }
}

The first method is simple with no exception. Then it throws an exception, and in subsequent methods, it finally returns an error object from OneOf. To make it realistic, each method will observe with 10% error and 90% success rate, as FailureEvery is set to 10. Success and Error are value types to avoid allocations, since they only return the value from the method.

Step 4: Run and test

dotnet run -c Release

The best performer is the NoException. But that is not practical, you have to identify unexpected behaviour and report it in the code flow. Firstly, a naive approach is to use an exception. Using it adds a time cost and increases the Garbage collector's Gen 0 pressure. So, our alternative to exception is OneOf, which significantly saved time and memory. We can further add Objects to the OneOf, considering the possible return values of the method.

In exceptions, Stack tracing is very expensive, as it propagates stacks, captures method names, stores IL offsets, and inspects frames. Also, the JIT inlining is limited during exceptions. With OneOfI used a struct value type, so Gen 0 utilization is minimized. Neither does it fall for stack trace nor unwind it. Hence, the execution remains linear.

When can I use an exception alternative?

In the following cases, exceptions can be replaced with Result or OneOf in normal application flows.

• Business rule rejection, such as the customers cannot order out-of-stock items. You can return an error in response.
• API validation, where you can simply return 400 with a custom message after figuring out all possible error cases.
• High-throughput paths where you cannot afford an exception mechanism.
• Validation failure, such as invalid email or mobile number input.
• Data not found scenarios where you know either the request data will be available or will not be found. Simply, you can deal with both cases.

When is an exception the optimal choice?

You don't remove fire alarms from a building because they're loud. You just don't pull them every time someone burns toast. We have some situations where exceptions stand out even if they are expensive.

• Exceptions occur when the program falls into an impossible state, such as when a null database connection is used. You cannot proceed anywhere because the connection is not even initialized for some reason.
• For environmental failures, you will opt for exceptions such as timeout failures, disk I/O failures, or database connection losses.
• Programming bugs where your code falls into a dead end, and it cannot handle further. Conditions where your input case exhaust, such as you have order statuses of pending, cancelled, and confirmed, are enumerated with 1,2 and 3, respectively. There is no case apart from that, so you can simply throw an ArgumentOutOfRangeException or a custom exception in the default case.
• If developing a library, use an exception to signal to the user what went wrong and halt normal execution. Here, you cannot force consumers to handle result types.

Conclusion

In high-performance systems, every allocation matters. Exceptions aim to provide a safeguard against anomalous conditions, but they can sometimes be a burden on memory and CPU. I put light on the exception of how much resource they can use for simple operations compared to their counterparts. We explored where it is suitable and where it can be replaced. In short, use exceptions for Unexpected, impossible, and environmental failures. While you can simply use Result/OneOf As an alternative, when conditions are expected, it is useful for business validation, user-driven errors, and high-frequency failures.

Code: https://github.com/elmahio-blog/ExceptionBenchmarks.git

APIs are the engine of modern applications. Your product belongs to any domain, either medical, banking, or IoT, APIs are most probable bricks in it. Good, maintainable, and reusable code promises a functional system. While a bad one makes maintenance and testing tedious. There is so much to care about in your application. In today's post, I will dig into writing a clean controller that fulfils the Single Responsibility Principle. We will see why exposing any business logic can harm the application and what exactly a controller should include.

Example with Fat Controller (bad design)

Consider the following ASP.NET Core controller implementation:

using System;
using Microsoft.AspNetCore.Mvc;

namespace EcCommerce.Controllers;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly ApplicationDbContext _context;

    public OrdersController(ApplicationDbContext context)
    {
        _context = context;
    }
        
    [HttpPost]
    public async Task<IActionResult> CreateOrder(CreateOrderRequest request)
    {
        var user = await _context.Users
            .Include(u => u.Orders)
            .FirstOrDefaultAsync(u => u.Id == request.UserId);
    
        if (user == null)
            return NotFound("User not found");
    
        if (!user.IsActive)
            return BadRequest("User is not active");
    
        if (request.TotalAmount <= 0)
            return BadRequest("Invalid order amount");
    
        var todayOrdersCount = user.Orders
            .Count(o => o.CreatedAt.Date == DateTime.UtcNow.Date);
    
        if (todayOrdersCount >= 5)
            return BadRequest("Daily order limit exceeded");
    
        var order = new Order
        {
            UserId = user.Id,
            TotalAmount = request.TotalAmount,
            CreatedAt = DateTime.UtcNow
        };
    
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    
        return Ok(order);
    }
}

The first thing in the code is that it is piercing to the eyes. Also, the controller knows too much of business logic and is really fat. If any business logic changes are required, we need to update the controller. Let's say we have to increase the daily order limit from 5 to 50, then we will need to update it here. Testing is difficult too, any test, even for business logic, will be done on the controller. All of that violates the DRY (Don't Repeat Yourself) and Single Responsibility Principles, as the controller is not inherently dedicated to these tasks. The example may look like I have added too much logic here, which people usually avoid, but you still need to be clear about exactly what the controllers should have. Many developers get confused and write a few lines of business logic where they shouldn't. The controllers should handle HTTP requests, validate the mapping, and return responses.

Business Rules Don't Leak Into Controllers

So, correcting the faulty controller here.

Step 1: Create a Domain Service

public interface IOrderService
{
    Task<Order> CreateOrderAsync(int userId, decimal totalAmount);
}

A very good way to encapsulate business logic is to introduce a service layer with an interface and its implementation, and inject them into the controller.

Step 2: Implementation of the domain service

public class OrderService : IOrderService
{
    private readonly ApplicationDbContext _context;

    public OrderService(ApplicationDbContext context)
    {
        _context = context;
    }

    public async Task<Order> CreateOrderAsync(int userId, decimal totalAmount)
    {
        var user = await _context.Users
            .Include(u => u.Orders)
            .FirstOrDefaultAsync(u => u.Id == userId);

        if (user == null)
            throw new Exception("User not found");

        if (!user.IsActive)
            throw new Exception("User is not active");

        if (totalAmount <= 0)
            throw new Exception("Invalid order amount");

        var todayOrdersCount = user.Orders
            .Count(o => o.CreatedAt.Date == DateTime.UtcNow.Date);

        if (todayOrdersCount >= 5)
            throw new Exception("Daily order limit exceeded");

        var order = new Order
        {
            UserId = user.Id,
            TotalAmount = totalAmount,
            CreatedAt = DateTime.UtcNow
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();

        return order;
    }
}

Sometimes, you can add a repository layer below the services and inject it instead of using ApplicationDbContext directly.

Step 3: Thin Controller

using System;
using Microsoft.AspNetCore.Mvc;

namespace EcCommerce.Controllers;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;

    public OrdersController(IOrderService orderService)
    {
        _orderService = orderService;
    }
        
    [HttpPost]
    public async Task<IActionResult> CreateOrder(CreateOrderRequest request)
    {
      
        var order = await _orderService
            .CreateOrderAsync(request.UserId, request.TotalAmount);
    
        return Ok(order);
    }
}

Now, we have a soothing code. Not to forget dependency injection in your Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Other injections

builder.Services.AddScoped<IOrderService, OrderService>();

Clean Architecture Style (Domain-Driven)

One more way you can deal is to define the logic in the domain itself.

User Model

public class User
{
    public bool IsActive { get; private set; }
    public List<Order> Orders { get; private set; } = new();

    public void CanPlaceOrder(decimal totalAmount)
    {
        if (!IsActive)
            throw new Exception("User is not active");

        if (totalAmount <= 0)
            throw new Exception("Invalid order amount");

        var todayOrders = Orders
            .Count(o => o.CreatedAt.Date == DateTime.UtcNow.Date);

        if (todayOrders >= 5)
            throw new Exception("Daily limit exceeded");
    }
}

Service

public class OrderService : IOrderService
{
    private readonly ApplicationDbContext _context;

    public OrderService(ApplicationDbContext context)
    {
        _context = context;
    }
    
    public async Task<Order> CreateOrderAsync(int userId, decimal totalAmount)
    {
        var user = await _context.Users
            .Include(u => u.Orders)
            .FirstOrDefaultAsync(u => u.Id == userId);
    
        if (user == null)
            throw new Exception("User not found");
    
        user.CanPlaceOrder(totalAmount);
    
        var order = new Order(userId, totalAmount);
    
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    
        return order;
    }
}

Dependency injection

var builder = WebApplication.CreateBuilder(args);

// Other injections

builder.Services.AddScoped<IOrderService, OrderService>();

Now the service becomes cleaner. In our corrected versions, we addressed all issues seen in the first code. If a new requirement asks to change the daily limit, we will go to the service or the domain model in a later example, and the controller will remain unaffected in both cases. Testing units are also made easy with the exposed method in the service. If any endpoint requires similar CreateOrder operations, then we can simply use it from OrderService, complying with the DRY principle. Our controller is now clean, and it adheres to the Single Responsibility Principle. The controller can only focus on validating requests and generating responses, while other tasks are handled in the underlying layers.

Conclusion

API controllers are responsible for exposing endpoints that your clients extensively rely on. They should validate the request, call the underlying layer like the service layer, and return the data. Keeping things in their place can help a lot with testing and maintenance, especially if your code is considerably large. One overlooked aspect is understanding exactly what a controller should contain. People often mistakenly add logic inside the controller method and fail to identify where to draw the line. I made it easy with this article and showed what potential problems can arise if business logic leaks inside the controller.

If you design an application with a data source, the repository pattern often comes to mind as a prominent choice. In fact, many developers see it as the default choice. However, the pattern is not helping every time. In this post, I will pinpoint some cases where the repository pattern is not the best choice.

What is a repository pattern?

The repository pattern is a design pattern that acts as an intermediate layer between data access and business logic. It abstracts the data source and implements the details, providing a clean representation of data manipulation as objects and lists.

Let us start by looking at how a repository pattern can be implemented with EF Core.

Start by adding a new model named Movie:

public class Movie
{
    public Guid Id { get; set; }
    public string Title { get; set; } = string.Empty;
    public string Director { get; set; } = string.Empty;
    public int ReleaseYear { get; set; }
    public double ImdbRating { get; set; }
    public DateTime CreatedAtUtc { get; set; } = DateTime.UtcNow;
}

Next, add a IMovieRepository interface with the basic methods for adding, getting, and saving movies:

public interface IMovieRepository
{
    Task AddAsync(Movie movie);
    Task<Movie?> GetByIdAsync(Guid id);
    Task<List<Movie>> GetTopRatedAsync(double minRating);
    Task SaveChangesAsync();
}

Add an implementation of that interface using EF Core:

public class MovieRepository : IMovieRepository
{
    private readonly AppDbContext _context;

    public MovieRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task AddAsync(Movie movie)
    {
        await _context.Movies.AddAsync(movie);
    }

    public async Task<Movie?> GetByIdAsync(Guid id)
    {
        return await _context.Movies.FindAsync(id);
    }

    public async Task<List<Movie>> GetTopRatedAsync(double minRating)
    {
        return await _context.Movies
            .Where(m => m.ImdbRating >= minRating)
            .OrderByDescending(m => m.ImdbRating)
            .ToListAsync();
    }

    public async Task SaveChangesAsync()
    {
        await _context.SaveChangesAsync();
    }
}

Finally, I'll add a service class that shows how to use the movie repository:

public class MovieService
{
    private readonly IMovieRepository _repository;

    public MovieService(IMovieRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> CreateMovieAsync(
        string title,
        string director,
        int releaseYear,
        double rating)
    {
        var movie = new Movie
        {
            Id = Guid.NewGuid(),
            Title = title,
            Director = director,
            ReleaseYear = releaseYear,
            ImdbRating = rating
        };

        await _repository.AddAsync(movie);
        await _repository.SaveChangesAsync();

        return movie.Id;
    }

    public async Task<List<Movie>> GetHighlyRatedMoviesAsync()
    {
        return await _repository.GetTopRatedAsync(8.0);
    }
}

If you are writing CRUD applications, implementing a data layer like this probably looks very familiar.

What are the advantages of the Repository pattern?

The repository pattern promises several key advantages.

• A clean separation of concerns where data access logic is centralized.
• Reusability, where the same repo methods can be used without copying the same logic again.

When to use the Repository pattern

Like any tool, it offers leverage only when in the right place. If you smell any scent in your code, go for the repository pattern.

• When your application does not rely on simple data storage or fetching but requires enquiring logic such as validation, projection, object preparation, or calculations. Domains such as insurance, banking, healthcare, and IoT require calculations, so the repository pattern can be helpful.
• The repository pattern can win for you if you are aggregating multiple data sources but presenting them as a single source to the upper layers. Usage of different data sources, such as MSSQL, Postgres, and external APIs, is kept hidden from the business logic layer.
• The repository layer can be handy if an application demands sophisticated caching strategies and you don't want to pollute the business layers. Hence, the service layer can be unaware of how the cache is configured, or even of whether the data comes from the cache or another source.
• For unit testing, you can employ the repository pattern, especially in error-critical systems such as financial systems, medical devices, and safety systems. Repositories enable you to test business logic in isolation by swapping real data access with test doubles. You can verify complex business rules, edge cases, and error handling without the overhead, unpredictability, and slowness of database tests.

When to avoid the Repository pattern

Well, we have seen the usefulness of the repository pattern. Now, rejoining our original question, "In what conditions can you avoid the repository pattern?"

• If your app is just basic Create, Read, Update, Delete operations without complex business logic, you simply go without it. A simple creation or fetch will not require verbose code, and adding a new layer will overengineer it.

For example, in the code, a repository pattern has simple operations:

public class UserRepository : IUserRepository 
{
    public User GetById(int id) => _context.Users.Find(id);
    public void Add(User user) => _context.Users.Add(user);
}

• With an ORM, you can avoid the abstraction layer. Most ORMs, such as Entity Framework Core, NHibernate, and Doctrine, already implement the repository pattern using DbSet and AppDbContext. You can simply deal with entities like collections and objects. If you don't have to add conditions, validation, and projections in the operations, you can choose simplicity. When wrapping an ORM in repositories, you are often hiding powerful features (like IQueryable for deferred execution or Include for eager loading) behind a more restrictive interface.
• Smaller projects also don't need to be tedious. If your project requires simple queries and consists of 10-15 tables, you are good to go without bombarding a small project with more code.
• Any abstraction comes with overhead. In a performance-critical system, a repository may not be the best choice for the same reason. Repository layers can require memory allocation, additional method calls, or complex query translation, which may slow down the software. Repositories often lead to the N+1 query problem or over-fetching data because the repository method returns a generic object rather than a specific projection (Select) tailored to the view.
• One more scenario where you can skip the repository pattern is in a microservice architecture. If a service is simple enough to have a small database and minimal operations, you don't need to trade off the repository pattern for maintenance and performance.
• While preparing reporting and analytics data, the repository pattern can be unnecessary. Mostly, the stored procedures, raw SQL queries, and database-specific optimizations do the whole job for us. The code only calls those underlying queries and returns. To keep things maintainable and, of course, speedy, you can avoid one layer.

Conclusion

The repository pattern is something you have probably used on your development journey. Why not? It is one of the popular choices for abstracting data access. However, abstractions have a hidden cost that I highlighted in the blog. I identified a few scenarios where you can escape it and barely lose anything. If you still want to use the repository pattern without losing its limitation, the specification pattern is another player that can work. It allows for reusable query logic without the bloat of a traditional repository.

For F1 racing, choosing the right car is as important as your expertise. No matter how skilled you are, if you race in an ordinary car, you can't stand out. You need to understand the race and use the F1 racing car. The same goes for programming. Going with the wrong option can hurt your application. If your application contains high-throughput junctions prone to bottlenecks, you are left with choices for different collections. Today, I will explore popular data collection options, including IEnumerable and List, and examine how IEnumerable can hinder hot paths.

IEnumerable in C#

IEnumerable is an interface that represents a forward-only sequence of elements. It represents a behaviour that can be deferred or materialized based on implementation. It exposes a single method, GetEnumerator() that returns an IEnumerator<T> object you can iterate sequentially. However, it does not support indexing.

List in C#

A list is a dynamic collection that resizes automatically and allows access to elements by index. The List class provides methods such as Add, Remove, and AddRange. A List is materialized, loading all data into memory. In fact, List implements IEnumerable.

IEnumerable analysis with benchmark

To observe actual ground effects, let's create a console application where we can benchmark IEnumerable with a concrete List.

Step 1: Create the project

dotnet new console -n IEnumerableBenchmark
cd IEnumerableBenchmark

Step 2: Install the BenchmarkDotNet library

dotnet add package BenchmarkDotNet

Step 3: Prepare the benchmarking code

Here, we will define everything in the Program.cs file:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;

BenchmarkRunner.Run<EnumerationBenchmarks>();

[MemoryDiagnoser]
public class EnumerationBenchmarks
{
    private List<int> _list = null!;
    private IEnumerable<int> _interfaceEnumerable = null!;
    private IEnumerable<int> _linqEnumerable = null!;
    private IEnumerable<int> _yieldEnumerable = null!;
    private int[] _array = null!;

    [Params(1000, 100_000)]
    public int N;

    [GlobalSetup]
    public void Setup()
    {
        // Independent data sources
        _list = Enumerable.Range(1, N).ToList();

        _array = Enumerable.Range(1, N).ToArray();

        _interfaceEnumerable = Enumerable.Range(1, N);

        _linqEnumerable = Enumerable.Range(1, N)
                                    .Where(x => x % 2 == 0)
                                    .Select(x => x * 2);

        _yieldEnumerable = CreateYieldSequence(N);
    }

    private IEnumerable<int> CreateYieldSequence(int count)
    {
        for (int i = 1; i <= count; i++)
        {
            if (i % 2 == 0)
                yield return i * 2;
        }
    }

    // -------------------------------
    // List - for (optimized)
    // -------------------------------
    [Benchmark(Baseline = true)]
    public int List_For()
    {
        int sum = 0;
        var list = _list;
        int count = list.Count;

        for (int i = 0; i < count; i++)
        {
            var x = list[i];
            if (x % 2 == 0)
                sum += x * 2;
        }

        return sum;
    }

    // -------------------------------
    // List - foreach
    // -------------------------------
    [Benchmark]
    public int List_Foreach()
    {
        int sum = 0;

        foreach (var x in _list)
        {
            if (x % 2 == 0)
                sum += x * 2;
        }

        return sum;
    }

    // -------------------------------
    // IEnumerable - foreach
    // -------------------------------
    [Benchmark]
    public int IEnumerable_Foreach()
    {
        int sum = 0;

        foreach (var x in _interfaceEnumerable)
        {
            if (x % 2 == 0)
                sum += x * 2;
        }

        return sum;
    }

    // -------------------------------
    // Array - foreach
    // -------------------------------
    [Benchmark]
    public int Array_Foreach()
    {
        int sum = 0;

        foreach (var x in _array)
        {
            if (x % 2 == 0)
                sum += x * 2;
        }

        return sum;
    }

    // -------------------------------
    // LINQ Deferred Execution
    // -------------------------------
    [Benchmark]
    public int Linq_Deferred()
    {
        return _linqEnumerable.Sum();
    }

    // -------------------------------
    // Yield State Machine
    // -------------------------------
    [Benchmark]
    public int Yield_Enumeration()
    {
        int sum = 0;

        foreach (var x in _yieldEnumerable)
        {
            sum += x;
        }

        return sum;
    }

    // -------------------------------
    // Multiple Enumeration
    // -------------------------------
    [Benchmark]
    public int Multiple_Enumeration()
    {
        int sum = 0;

        if (_linqEnumerable.Any())
        {
            foreach (var x in _linqEnumerable)
            {
                sum += x;
            }
        }

        return sum;
    }

    // -------------------------------
    // Span<T>
    // -------------------------------
    [Benchmark]
    public int Span_For()
    {
        int sum = 0;
        var span = CollectionsMarshal.AsSpan(_list);

        for (int i = 0; i < span.Length; i++)
        {
            var x = span[i];
            if (x % 2 == 0)
                sum += x * 2;
        }

        return sum;
    }
}

I defined a list and an IEnumerable. In the Setup, we will initialize each one with 1000 and 100000 elements. There are several other testers to get how IEnumerable performs as deferred and as materialized collections, as shown in the methods.

Step 4: Run the project

Let's run our project in release mode

dotnet run -c Release

So, the results show the cost of IEnumerable.

As per the results, List outperformed IEnumerable by up to 7x. Thanks to contiguous memory allocation and JITs array optimization, arrays outclass the list, too. But flexibility and numerous handy methods make the list more usable in most scenarios. The single test does not prove that IEnumerable should be abandoned. In fact, you will not want to overload memory by loading the entire dataset if it is extremely large. Then theIEnumerable's behaviour took effect. The List is a help for small to medium-sized collections and requires frequent manipulation, such as adding and removing items. As immediate execution loads data immediately, lists are ideal when you need data to be readily available and need frequent manipulation.

Using IEnumerable in hot paths slows performance and does not support data manipulation. Usually, applications do not load all data at once; instead, they use filtering or pagination when fetching data. In such cases, lists leverage immediate execution.

Conclusion

We may not need to emphasize the importance of performance in any application. We already know the importance of keeping the operations as fast as possible. Identifying and mitigating the hot path is one link in this chain. I shared one underrated point about using the right collection in such bottleneck areas. Being cautious about IEnumerable in hot paths, can be good for the application and your peace of mind.

Code: https://github.com/elmahio-blog/IEnumerableBenchmark

Database schema and entity design are the pavement of most applications. If the entities are paved well, the application can provide great performance. Otherwise, it can lead to pitfalls. One key aspect of entity design is dealing with polymorphic relationships. EF Core supports several ways to implement inheritance, so in this post, I will explore the best ways to handle these relationships.

To see these concepts in action, we need to look at the specific implementation strategies EF Core offers. We will start with the most common approach, which maps an entire class hierarchy to a single database table.

Table-per-Hierarchy (TPH) Inheritance (EF Core-native) polymorphic relationship implementation

One polymorphic relationship EF Core provides is Table-per-Hierarchy (TPH). A single table stores data for all inherited types, differentiated by a discriminator column. I will use an enum for the discriminator. In fact, TPH is the default mapping of EF Core. Let us create a project to showcase TPH.

Step 1: Create a project

dotnet new console -o EfCoreTph

Step 2: Install the required packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

Step 3: Define models

Add the discriminator enum:

public enum EmployeeTypeEnum: byte
{
    FullTimeEmployee = 1,
    PartTimeEmployee = 2,
    Contractor = 3
}

Add the model Employee:

public abstract class Employee
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public DateTime HireDate { get; set; } = DateTime.UtcNow.Date;
    public decimal BaseSalary { get; set; }
}

I've made it abstract to function as a base class. Next, add the Contractor sub-class:

public class Contractor: Employee
{
    public DateTime ContractEndDate { get; set; }
    public string AgencyName { get; set; } = string.Empty;
}

And add another subclass named FullTimeEmployee:

public class FullTimeEmployee: Employee
{
    public decimal AnnualBonus { get; set; }
    public int VacationDays { get; set; }
}

And finally, add the PartTimeEmployee subclass:

public class PartTimeEmployee: Employee
{
    public decimal HourlyRate { get; set; }
    public int WeeklyHours { get; set; }
}

Step 4: Set up DbContext

As a decisive step, I will specify how I want to handle relationships.

using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext: DbContext
{
    public DbSet<Employee> Employees => Set<Employee>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseNpgsql(
            "Connection string with db name tphDb");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Employee>()
            .HasDiscriminator<EmployeeTypeEnum>("EmployeeType")
            .HasValue<FullTimeEmployee>(EmployeeTypeEnum.FullTimeEmployee)
            .HasValue<PartTimeEmployee>(EmployeeTypeEnum.PartTimeEmployee)
            .HasValue<Contractor>(EmployeeTypeEnum.Contractor);
    }
}

Inside the OnModelCreating method, I configure EF Core to store all derived types in a single table and use a column to indicate which CLR type each row represents, following TPH. That discriminator is EmployeeType, which in this case is an enum.

Step 5: Configure Program.cs

using Microsoft.EntityFrameworkCore;

using var db = new ApplicationDbContext();

var fullTime = new FullTimeEmployee
{
    Name = "Ali Hamza",
    Email = "ali@company.com",
    HireDate = DateTime.UtcNow.AddYears(-2),
    BaseSalary = 150000,
    AnnualBonus = 30000,
    VacationDays = 25
};

var partTime = new PartTimeEmployee
{
    Name = "James Anderson",
    Email = "james@anderson.com",
    HireDate = DateTime.UtcNow.AddMonths(-6),
    BaseSalary = 0,
    HourlyRate = 1200,
    WeeklyHours = 20
};

var contractor = new Contractor
{
    Name = "Frank Doe",
    Email = "Frank@agency.com",
    HireDate = DateTime.UtcNow.AddMonths(-3),
    BaseSalary = 0,
    ContractEndDate = DateTime.UtcNow.AddMonths(9),
    AgencyName = "TechStaff Ltd"
};

db.Employees.AddRange(fullTime, partTime, contractor);
db.SaveChanges();

Console.WriteLine("Employees inserted.");

var partTimers = 
    await db.Employees.OfType<PartTimeEmployee>().ToListAsync();

foreach (var item in partTimers)
{
    Console.WriteLine(item.Name);
    Console.WriteLine(item.Email);
    Console.WriteLine(item.HireDate);
    Console.WriteLine(item.BaseSalary);
    Console.WriteLine(item.WeeklyHours);
    Console.WriteLine(item.HourlyRate);
}

var employees = await db.Employees.ToListAsync();

foreach (var emp in employees)
{
    Console.WriteLine($"[{emp.GetType().Name}] {emp.Name}");

    if (emp is FullTimeEmployee fte)
    {
        Console.WriteLine($"  Bonus: {fte.AnnualBonus}");
    }
    else if (emp is PartTimeEmployee pte)
    {
        Console.WriteLine($"  Hourly Rate: {pte.HourlyRate}");
    }
    else if (emp is Contractor c)
    {
        Console.WriteLine($"  Agency: {c.AgencyName}");
    }
}

We can fetch records either by a specific type, like PartTimeEmployee or with Employees using the polymorphic nature.

Step 6: Run migration

Migrate the database with all of the changes:

dotnet ef migrations add InitialDb

dotnet ef database update

Let us look inside the InitialDb migration to see the generated code:

using System;
using Microsoft.EntityFrameworkCore.Migrations;
using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata;

#nullable disable

namespace EfCoreTph.Migrations
{
    /// <inheritdoc />
    public partial class InitialDb : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.CreateTable(
                name: "Employees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false)
                        .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Email = table.Column<string>(type: "text", nullable: false),
                    HireDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    BaseSalary = table.Column<decimal>(type: "numeric", nullable: false),
                    EmployeeType = table.Column<byte>(type: "smallint", nullable: false),
                    ContractEndDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: true),
                    AgencyName = table.Column<string>(type: "text", nullable: true),
                    AnnualBonus = table.Column<decimal>(type: "numeric", nullable: true),
                    VacationDays = table.Column<int>(type: "integer", nullable: true),
                    HourlyRate = table.Column<decimal>(type: "numeric", nullable: true),
                    WeeklyHours = table.Column<int>(type: "integer", nullable: true)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Employees", x => x.Id);
                });
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.DropTable(
                name: "Employees");
        }
    }
}

A single table is created, with all common properties non-nullable and type-specific properties nullable.

The table and seed data in the database look like this:

We observe that type-specific columns are null for records of other types.

Step 7: Run and test the application

Let's run the project:

dotnet run

When is TPH best

• For domain-driven design, TPH is best suited to lower complexity and is fully supported by EF Core.
• It offers the least complexity, and LINQ works naturally.
• Optimal when types are closely related, and there are fewer chances of null values.

When to avoid TPH

• Sometimes strength becomes a liability. So is the case with TPH. If your entities are unrelated, then a single table can be overwhelmed by null values.
• Due to null columns, TPH can be inefficient if you have too many derived entities.

Table-Per-Type (TPT) EF core polymorphic relationship implementation

Another type of relationship EF offers is Table-Per-Type (TPT). As the name suggests, parent and child entities contain their own table joined via foreign keys. Let's check how we can do it with a new sample project.

Step 1: Create a project

dotnet new console -o EfCoreTpt

Step 2: Install the required packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

Step 3: Define models

We will create the same models as in the sample above.

Step 4: Set up DbContext

using Microsoft.EntityFrameworkCore;

namespace EfCoreTpt.Data;

public class ApplicationDbContext: DbContext
{
    public DbSet<Employee> Employees => Set<Employee>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseNpgsql(
            "connection string with db name tptDb");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Employee>().UseTptMappingStrategy();

        modelBuilder.Entity<FullTimeEmployee>().ToTable("FullTimeEmployees");
        modelBuilder.Entity<PartTimeEmployee>().ToTable("PartTimeEmployees");
        modelBuilder.Entity<Contractor>().ToTable("Contractors");
    }
}

Here, with UseTptMappingStrategy I have to specify the base type of Employee with TPT mapping. You can see that other types are also mapped to their table.

Step 5: Configure Program.cs

using var db = new ApplicationDbContext();

var fullTime = new FullTimeEmployee
{
    Name = "Ali Hamza",
    Email = "ali@company.com",
    HireDate = DateTime.UtcNow.AddYears(-2),
    BaseSalary = 150000,
    AnnualBonus = 30000,
    VacationDays = 25
};

var partTime = new PartTimeEmployee
{
    Name = "James Anderson",
    Email = "james@anderson.com",
    HireDate = DateTime.UtcNow.AddMonths(-6),
    BaseSalary = 0,
    HourlyRate = 1200,
    WeeklyHours = 20
};

var contractor = new Contractor
{
    Name = "Frank Doe",
    Email = "Frank@agency.com",
    HireDate = DateTime.UtcNow.AddMonths(-3),
    BaseSalary = 0,
    ContractEndDate = DateTime.UtcNow.AddMonths(9),
    AgencyName = "TechStaff Ltd"
};

db.Employees.AddRange(fullTime, partTime, contractor);
db.SaveChanges();

Console.WriteLine("Employees inserted.");

var employees = db.Employees.ToList();

foreach (var emp in employees)
{
    Console.WriteLine($"[{emp.GetType().Name}] {emp.Name}");

    switch (emp)
    {
        case FullTimeEmployee f:
            Console.WriteLine($"  Bonus: {f.AnnualBonus}");
            break;

        case PartTimeEmployee p:
            Console.WriteLine($"  Hourly: {p.HourlyRate}");
            break;

        case Contractor c:
            Console.WriteLine($"  Agency: {c.AgencyName}");
            break;
    }
}

Step 6: Run migration

Again, let us update the database:

dotnet ef migrations add InitialDb

dotnet ef database update

And look at the generated migration class:

using System;
using Microsoft.EntityFrameworkCore.Migrations;
using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata;

#nullable disable

namespace EfCoreTpt.Migrations
{
    /// <inheritdoc />
    public partial class InitialDb : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.CreateTable(
                name: "Employees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false)
                        .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Email = table.Column<string>(type: "text", nullable: false),
                    HireDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    BaseSalary = table.Column<decimal>(type: "numeric", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Employees", x => x.Id);
                });

            migrationBuilder.CreateTable(
                name: "Contractors",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false),
                    ContractEndDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    AgencyName = table.Column<string>(type: "text", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Contractors", x => x.Id);
                    table.ForeignKey(
                        name: "FK_Contractors_Employees_Id",
                        column: x => x.Id,
                        principalTable: "Employees",
                        principalColumn: "Id",
                        onDelete: ReferentialAction.Cascade);
                });

            migrationBuilder.CreateTable(
                name: "FullTimeEmployees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false),
                    AnnualBonus = table.Column<decimal>(type: "numeric", nullable: false),
                    VacationDays = table.Column<int>(type: "integer", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_FullTimeEmployees", x => x.Id);
                    table.ForeignKey(
                        name: "FK_FullTimeEmployees_Employees_Id",
                        column: x => x.Id,
                        principalTable: "Employees",
                        principalColumn: "Id",
                        onDelete: ReferentialAction.Cascade);
                });

            migrationBuilder.CreateTable(
                name: "PartTimeEmployees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false),
                    HourlyRate = table.Column<decimal>(type: "numeric", nullable: false),
                    WeeklyHours = table.Column<int>(type: "integer", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_PartTimeEmployees", x => x.Id);
                    table.ForeignKey(
                        name: "FK_PartTimeEmployees_Employees_Id",
                        column: x => x.Id,
                        principalTable: "Employees",
                        principalColumn: "Id",
                        onDelete: ReferentialAction.Cascade);
                });
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.DropTable(
                name: "Contractors");

            migrationBuilder.DropTable(
                name: "FullTimeEmployees");

            migrationBuilder.DropTable(
                name: "PartTimeEmployees");

            migrationBuilder.DropTable(
                name: "Employees");
        }
    }
}

One notable aspect here is the use of foreign keys to link tables. TPT is the only one that uses foreign keys to represent the inheritance itself. Other strategies can still use FKs for normal relationships (like Employee has a Laptop).

The database and data now look like this:

Although I added records using the base class, they are written into their respective tables.

Step 7: Run and test the application

dotnet run

EF Core generates joins in every query, such as:

SELECT ...
FROM Employees e
LEFT JOIN FullTimeEmployees f ON e.Id = f.Id
LEFT JOIN PartTimeEmployees p ON e.Id = p.Id
LEFT JOIN Contractors c ON e.Id = c.Id

When is TPT best

• With each type having its own table, the database schema remained clean.
• The database is inherently well normalized.
• Records contain minimal nulls. TPT is optimal when your application has big inheritance trees.

When to avoid TPT

• TPT can be problematic in performance-critical systems, potentially slowing data reading.
• Queries heavily rely on joins.

Table-Per-Concrete (TPC) EF Core polymorphic relationship implementation

The last approach in EF Core polymorphic relationships is Table-Per-Concrete-Class (TPC). The parent class has no table, while each concrete class contains its own table. Each table repeats inherited fields as its columns. Like with the previous types, let us create a sample project to show how it works.

Step 1: Create a project

dotnet new console -o EfCoreTpc

Step 2: Install the required packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

Step 3: Define models

We will use the same models as in the sample above.

Step 4: Set up DbContext

This is the most crucial step, as with the others. Here, I will specify how I want to deal with relationships:

using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext: DbContext
{
    public DbSet<Employee> Employees => Set<Employee>();
    public DbSet<FullTimeEmployee> FullTimeEmployees => Set<FullTimeEmployee>();
    public DbSet<PartTimeEmployee> PartTimeEmployees => Set<PartTimeEmployee>();
    public DbSet<Contractor> Contractors => Set<Contractor>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseNpgsql(
            "Connectionstring with db name tpcDb");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Employee>()
            .UseTpcMappingStrategy();
    }
}

The code modelBuilder.Entity().UseTpcMappingStrategy() instructs EF Core to use TPC mappings.

Step 5: Configure Program.cs

using var db = new ApplicationDbContext();

var fullTime = new FullTimeEmployee
{
    Name = "Ali Hamza",
    Email = "ali@company.com",
    HireDate = DateTime.UtcNow.AddYears(-2),
    BaseSalary = 150000,
    AnnualBonus = 30000,
    VacationDays = 25
};

var partTime = new PartTimeEmployee
{
    Name = "James Anderson",
    Email = "james@anderson.com",
    HireDate = DateTime.UtcNow.AddMonths(-6),
    BaseSalary = 0,
    HourlyRate = 1200,
    WeeklyHours = 20
};

var contractor = new Contractor
{
    Name = "Frank Doe",
    Email = "Frank@agency.com",
    HireDate = DateTime.UtcNow.AddMonths(-3),
    BaseSalary = 0,
    ContractEndDate = DateTime.UtcNow.AddMonths(9),
    AgencyName = "TechStaff Ltd"
};

db.Employees.AddRange(fullTime, partTime, contractor);
db.SaveChanges();

Console.WriteLine("Employees inserted.");

var employees = db.Employees.ToList();

foreach (var emp in employees)
{
    Console.WriteLine($"[{emp.GetType().Name}] {emp.Name}");
}

Here, I am leveraging polymorphic behaviour by inserting records into the Employees data set.

Step 6: Run migration

Create a migration and update the database:

dotnet ef migrations add InitialDb

dotnet ef database update

The new migration class looks like this:

using System;
using Microsoft.EntityFrameworkCore.Migrations;

#nullable disable

namespace EfCoreTpc.Migrations
{
    /// <inheritdoc />
    public partial class InitialDb : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.CreateSequence(
                name: "EmployeeSequence");

            migrationBuilder.CreateTable(
                name: "Contractors",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false, defaultValueSql: "nextval('\"EmployeeSequence\"')"),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Email = table.Column<string>(type: "text", nullable: false),
                    HireDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    BaseSalary = table.Column<decimal>(type: "numeric", nullable: false),
                    ContractEndDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    AgencyName = table.Column<string>(type: "text", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Contractors", x => x.Id);
                });

            migrationBuilder.CreateTable(
                name: "FullTimeEmployees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false, defaultValueSql: "nextval('\"EmployeeSequence\"')"),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Email = table.Column<string>(type: "text", nullable: false),
                    HireDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    BaseSalary = table.Column<decimal>(type: "numeric", nullable: false),
                    AnnualBonus = table.Column<decimal>(type: "numeric", nullable: false),
                    VacationDays = table.Column<int>(type: "integer", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_FullTimeEmployees", x => x.Id);
                });

            migrationBuilder.CreateTable(
                name: "PartTimeEmployees",
                columns: table => new
                {
                    Id = table.Column<int>(type: "integer", nullable: false, defaultValueSql: "nextval('\"EmployeeSequence\"')"),
                    Name = table.Column<string>(type: "text", nullable: false),
                    Email = table.Column<string>(type: "text", nullable: false),
                    HireDate = table.Column<DateTime>(type: "timestamp with time zone", nullable: false),
                    BaseSalary = table.Column<decimal>(type: "numeric", nullable: false),
                    HourlyRate = table.Column<decimal>(type: "numeric", nullable: false),
                    WeeklyHours = table.Column<int>(type: "integer", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_PartTimeEmployees", x => x.Id);
                });
        }

        /// <inheritdoc />
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.DropTable(
                name: "Contractors");

            migrationBuilder.DropTable(
                name: "FullTimeEmployees");

            migrationBuilder.DropTable(
                name: "PartTimeEmployees");

            migrationBuilder.DropSequence(
                name: "EmployeeSequence");
        }
    }
}

The code migrationBuilder.CreateSequence(name: "EmployeeSequence") specifies global ID generation across the hierarchy. Instead of independent identity generators, EF Core uses one shared sequence.

The database now looks like this:

Step 7: Run and test the application

dotnet run

A high-level view of the generated query is:

SELECT ... FROM FullTimeEmployees
UNION ALL
SELECT ... FROM PartTimeEmployees
UNION ALL
SELECT ... FROM Contractors

And the rows returned look like in the following screenshots:

When is TPC best

• TPC applies when the application requires performing extensive queries on concrete types.
• When you are designing a fast read-heavy system.
• When you want to keep clean tables with no nulls.

When to avoid TPC

• TPC can slow down when the application has many polymorphic queries.
• Do not use with large inheritance trees.
• Not optimal, frequent schema changes.
• Duplicated columns can be problematic for some users.

Conclusion

Entity Framework provides different ways to design entities. They are not fixed for any use, but we tried to see by example how each one creates tables and how its internal relationships work. A quick summary of the types and features can be seen here:

In this blog post, I delved deeper into TPH, TPT, and TPC. I hope it helps you decide on which strategy to use for your database design.

Code: https://github.com/elmahio-blog/PolymorphicRelEfCore

As developers, we know that user requests can be unpredictable. When they request data, it is either successfully returned or not found. However, a "not found" result usually happens in two ways. First, the user might request a record, such as a basketball player, by passing an ID that doesn't exist. Second, they might pass the wrong type of ID, like a Team ID, while trying to fetch a Player. The first situation is common, but the second should be handled to avoid logic pitfalls. Enforcing this validation for every entity can be a humongous task when your application contains hundreds of entities. In this post, I will provide a way out of this situation so you can restrict your application from passing IDs interchangeably among entities.

Primitive obsession

Primitive obsession refers to a situation where we use primitive data types, such as int, string, or bool, to represent complex data. Usually, values like URLs, Addresses, or identities are saved as strings. This creates a hidden breach of encapsulation because it forces you to add an extra layer of validation somewhere else in the code.

For domain-specific entities like URLs or addresses, you can use owned entities. However, to define domain-specific identities, we need strongly-typed IDs.

Primitive Id implementation for EF Core model entity

Let's first understand the problem with the traditional way. I will create a console application with a PostgreSQL database to catch the issue at hand.

Step 1: Create the project

dotnet new console -n IntIdsDemo
cd IntIdsDemo

Step 2: Install necessary packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

Step 3: Define models

I'll create models to represent a player, a team, and the relationship between them.

Player

namespace IntIdsDemo.Domain.Entities;

public class Player
{
    public int Id { get; private set; }
    public string Name { get; private set; } = string.Empty;

    private Player() { } // Required by EF Core

    public Player(string name)
    {
        Name = name;
    }
}

Team

namespace IntIdsDemo.Domain.Entities;

public class Team
{
    public int Id { get; private set; }
    public string Name { get; private set; } = string.Empty;

    private Team() { } 

    public Team(string name)
    {
        Name = name;
    }
}

PlayerTeam to join them

namespace IntIdsDemo.Domain.Entities;

public class PlayerTeam
{
    public int Id { get; private set; }
    public int PlayerId { get; set; }
    public int TeamId { get; set; }

    private PlayerTeam() { }

    public PlayerTeam(int playerId, int teamId)
    {
        PlayerId = playerId;
        TeamId = teamId;
    }
}

Step 4: Configure ApplicationDbContext

using IntIdsDemo.Domain.Entities;
using Microsoft.EntityFrameworkCore;

namespace IntIdsDemo.Data;

public class ApplicationDbContext: DbContext
{
    public DbSet<Player> Players => Set<Player>();
    public DbSet<Team> Teams => Set<Team>();
    public DbSet<PlayerTeam> PlayerTeams => Set<PlayerTeam>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseNpgsql(
            "Connection string with database simpleIdsDb");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {        
    }
}

Step 5: Define Program.cs

using IntIdsDemo.Data;
using IntIdsDemo.Domain.Entities;

using var db = new ApplicationDbContext();

// Seed data
var player1 = new Player("Ali");
var player2 = new Player("Hamza");
var team = new Team("Warriors");

db.Players.Add(player1);
db.Players.Add(player2);
db.Teams.Add(team);
db.SaveChanges();

Console.WriteLine("Player & Team saved");

// Simple assignment method
void AssignPlayerToTeam(int playerId, int teamId)
{
    var playerTeam = new PlayerTeam(playerId, teamId);
    db.PlayerTeams.Add(playerTeam);
    db.SaveChanges();
}

AssignPlayerToTeam(player2.Id, team.Id);
AssignPlayerToTeam(team.Id, player2.Id);

Player player = db.Players.Find(team.Id);

if (player != null)
{
    Console.WriteLine($"Player Id (int): {player.Id}");
    Console.WriteLine($"Player Name: {player.Name}");
}

player = db.Players.Find(player2.Id);

if (player != null)
{
    Console.WriteLine($"Player Id (int): {player.Id}");
    Console.WriteLine($"Player Name: {player.Name}");
}

I am initializing 2 players and 1 team here. Later, I assign player 2 to the team. First, I did it correctly as per the method's requirement, with AssignPlayerToTeam(player2.Id, team.Id); While in the second part, which is logically wrong, the compiler will give a green signal to AssignPlayerToTeam(team.Id, player2.Id). Next, I am observing an issue with fetching data. I can easily pass teamId as the parameter for the Find method, where playerId (db.Players.Find(team.Id)) is expected. But since we are using the primitive type of int, it will compile without any errors.

Step 6: Run the migration

We need to create an empty database

CREATE DATABASE simpleIdsDb;

And create a migration and update the database

dotnet ef migrations add InitialCreate
dotnet ef database update

Step 7: run the project

dotnet run

Let's check the database. The Players table contains the following rows:

The Teams table contains a single row:

And finally, the PlayerTeams table contains two relationship rows:

As you can see, the assignment is done, and PlayerId and TeamId were assigned interchangeably. To prevent this at the database level, we would have to add specific constraints. However, at the coding level, this remains a significant issue. While the console output shows that the player was not found with team.Id, this behavior can still lead to data inconsistency or unexpected runtime errors.

Strongly-Typed ID implementation for safer domain model

To keep focus on strongly-typed ID implementations, I will continue a similar project.

Step 1: Create the project

dotnet new console -n StronglyTypedIdsDemo
cd StronglyTypedIdsDemo

Step 2: Install necessary packages

dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

Step 3: Create the Strongly-Typed IDs

Traversing to the directory Domain/Ids/ and add the following code for creating a player ID

namespace StronglyTypedIdsDemo.Domain.Ids;

public readonly record struct PlayerId(int Value)
{
    public override string ToString() => Value.ToString();
}

And the following for creating a team ID

namespace StronglyTypedIdsDemo.Domain.Ids;

public readonly record struct TeamId(int Value)
{
    public override string ToString() => Value.ToString();
}

And finally, the player/team relational ID

namespace StronglyTypedIdsDemo.Domain.Ids;

public readonly record struct PlayerTeamId(int Value)
{
    public override string ToString() => Value.ToString();
}

struct are the best fit for strongly-typed IDs. A struct cannot contain null, while a class would allow it null, heap allocation, and reference semantics. readonly ensures immutability and cannot be modified after creation. As we know record is a value object, record struct will give you value-based equality automatically.

Step 4: Create the Entity

Go to the directory StronglyTypedIdsDemo.Domain.Entities and add the following model classes

using StronglyTypedIdsDemo.Domain.Ids;

namespace StronglyTypedIdsDemo.Domain.Entities;

public class Player
{
    public PlayerId Id { get; private set; }
    public string Name { get; private set; } = string.Empty;

    private Player() { } 

    public Player(string name)
    {
        Name = name;
    }
}

using StronglyTypedIdsDemo.Domain.Ids;

namespace StronglyTypedIdsDemo.Domain.Entities;

public class Team
{
    public TeamId Id { get; private set; }
    public string Name { get; private set; } = string.Empty;

    private Team() { } 

    public Team(string name)
    {
        Name = name;
    }
}

using StronglyTypedIdsDemo.Domain.Ids;

namespace StronglyTypedIdsDemo.Domain.Entities;

public class PlayerTeam
{
    public PlayerTeamId Id { get; private set; }
    public PlayerId PlayerId { get; private set; }
    public TeamId TeamId { get; private set; }

    private PlayerTeam() { }

    public PlayerTeam(PlayerId playerId, TeamId teamId)
    {
        PlayerId = playerId;
        TeamId = teamId;
    }
}

These classes look similar to the first application but all ID types have been switched out for the strongly typed versions.

Step 5: Configure the DbContext

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Storage.ValueConversion;
using StronglyTypedIdsDemo.Domain.Entities;
using StronglyTypedIdsDemo.Domain.Ids;

namespace StronglyTypedIdsDemo.Data;

public class ApplicationDbContext: DbContext
{
    public DbSet<Player> Players => Set<Player>();
    public DbSet<Team> Teams => Set<Team>();
    public DbSet<PlayerTeam> PlayerTeams => Set<PlayerTeam>();

    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseNpgsql(
            "Connection string with db name strongIdsDb");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        var playerIdConverter = new ValueConverter<PlayerId, int>(
            id => id.Value,
            value => new PlayerId(value));

        modelBuilder.Entity<Player>(entity =>
        {
            entity.HasKey(x => x.Id);

            entity.Property(x => x.Id)
                .HasConversion(playerIdConverter)
                .ValueGeneratedOnAdd();

            entity.Property(x => x.Name)
                .IsRequired();
        });
        
        var teamIdConverter = new ValueConverter<TeamId, int>(
            id => id.Value,
            value => new TeamId(value));

        modelBuilder.Entity<Team>(entity =>
        {
            entity.HasKey(x => x.Id);

            entity.Property(x => x.Id)
                .HasConversion(teamIdConverter)
                .ValueGeneratedOnAdd();

            entity.Property(x => x.Name)
                .IsRequired();
        });
        
        var playerTeamIdConverter = new ValueConverter<PlayerTeamId, int>(
            id => id.Value,
            value => new PlayerTeamId(value));

        modelBuilder.Entity<PlayerTeam>(entity =>
        {
            entity.HasKey(x => x.Id);

            entity.Property(x => x.Id)
                .HasConversion(playerTeamIdConverter)
                .ValueGeneratedOnAdd();

            entity.Property(pt => pt.PlayerId)
                .HasConversion(playerIdConverter)
                .IsRequired();

            entity.Property(pt => pt.TeamId)
                .HasConversion(teamIdConverter)
                .IsRequired();
        });
    }
}

I used ValueConverter<PlayerId, int> that tells EF Core to use PlayerId but save the value as int. similarly TeamId and PlayerTeamId are configured. Notice that adding a connection string through code is not recommended and only done for simplicity. Always use external configuration for this.

Step 6: Configure Program.cs

using StronglyTypedIdsDemo.Data;
using StronglyTypedIdsDemo.Domain.Entities;
using StronglyTypedIdsDemo.Domain.Ids;

using var db = new ApplicationDbContext();

// Seed data
var player1 = new Player("Ali");
var player2 = new Player("Hamza");
var team = new Team("Warriors");

db.Players.Add(player1);
db.Players.Add(player2);
db.Teams.Add(team);
db.SaveChanges();

Console.WriteLine("Player & Team saved");

// Simple assignment method
void AssignPlayerToTeam(PlayerId playerId, TeamId teamId)
{
    var playerTeam = new PlayerTeam(playerId, teamId);
    db.PlayerTeams.Add(playerTeam);
    db.SaveChanges();
}

AssignPlayerToTeam(player2.Id, team.Id);

// ⚠️ Wrong order of parameter
AssignPlayerToTeam(team.Id, player2.Id);

// ⚠️ Wrong ID type for Find
Player player = db.Players.Find(team.Id);

if (player != null)
{
    Console.WriteLine($"Player Id (int): {player.Id}");
    Console.WriteLine($"Player Name: {player.Name}");
}

player = db.Players.Find(player2.Id);

if (player != null)
{
    Console.WriteLine($"Player Id (int): {player.Id}");
    Console.WriteLine($"Player Name: {player.Name}");
}

In the code, I'm adding a record manually . In the line AssignPlayerToTeam(team.Id, player2.Id), a compiler error is shown.

The compiler now detects when we try to use the incorrect IDs when adding a user to a team.

Sep 7: run migrations

We need to create an empty database

CREATE DATABASE strongIdsDb;

And add the migration and run it

dotnet ef migrations add InitialCreate
dotnet ef database update

Step 8: Run and test

dotnet run

The second error is now revealed, since we are trying to use a team ID as the parameter for the Find method on the Players table

This means we are on the right track. Remove erroneous code and everything looks great

What strongly-typed IDs have improved?

• Primitive IDs can lead to id-mixup at compile time. Defining identity structure. Each entity eliminates this shortcoming.
• The traditional approach lacks domain meaning, whereas a strongly typed ID contains explicit intent.
• Strongly-typed IDs removed the ambiguity of method signatures that happens when int, Guid, or other primitive types are used.
• Traditionally, bugs are skipped at compile time, leading to runtime errors, while strongly-typed IDs catch ID mismatches at compile time.

Conclusion

Robustness is a big win for any application. Your code should handle issues right at the gateway. One common problem most people overlook is primitive obsession. Using types like ints for IDs allows you to pass IDs of different entities interchangeably. You can validate them manually, but that requires extra verbose code elsewhere, which breaks encapsulation. In this post, I have provided a solution using strongly-typed IDs to resolve that problem. We first looked at the traditional approach and observed the real-world issues caused by primitive obsession. Using separate value-object IDs makes your domain model much safer.

Code: https://github.com/elmahio-blog/StronglyTypedIdsDemo

.NET 10 is officially out, along with C# 14. Microsoft has released .NET 10 as Long-Term Support (LTS) as a successor to .NET 8. Like every version, it is not just an update but brings something new to the table. In this series, we will explore which aspects of software can be upgraded with the latest release. Today, we will explore a multi-tenant rate limiter with .NET 10.

APIs power your business. The statement is mostly true for all of your applications. The user accesses the information via mobile or web, and you provide it to them via an API. For SaaS, the access and information have more to manage from client to client. A premium client pays more and needs more throughput. Similarly, others will use the system according to their plan and user base. One factor of fair use among clients or tenants is rate limiting, that is, how many requests users of a client can hit the server. .NET 10 offers improvements in rate-limiting with its throttling middleware.

Designing a multi-tenant rate limiter

To understand the multi-tenant rate limiter, we will create a simple web API. I will provide step-by-step instructions to break this down with .NET 10.

Step 1: Create a .NET API project

dotnet new webapi -n Net10RateLimiter -f net10.0
cd Net10RateLimiter

Step 2: Create Models

I organized models in the Models folder and created the following class:

namespace Net10RateLimiter.Models;

public class TenantRateLimit
{
    public string TenantId { get; set; } = string.Empty;
    public int RequestsPerMinute { get; set; }
}

The class TenantRateLimit will define a tenant-specific rate using OOP. For a database-based application, we can save it as well.

Step 3: Create a Limit resolver service

For that logic, I created a folder named Services, and the resolver class look like this:

namespace Net10RateLimiter.Services;

public sealed class TenantResolver
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public TenantResolver(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public string ResolveTenant()
    {
        var context = _httpContextAccessor.HttpContext;

        if (context is null)
            return "default";

        if (context.Request.Headers.TryGetValue("X-Tenant-ID", out var tenantId))
            return tenantId.ToString();

        return "default";
    }
}

The resolver works as request-scoped logic to invalidate limits on each request. It extracts the tenant identity from the incoming request and returns.

Step 4: Register Required Services

Inject the required dependencies in Program.cs

builder.Services.AddControllers();

// Required for HttpContext access
builder.Services.AddHttpContextAccessor();

// Tenant resolver must be scoped
builder.Services.AddScoped<TenantResolver>();

Step 5: Add rate limiting logic

Just after the dependency injections, add the following code:

builder.Services.AddRateLimiter(options =>
{
    options.OnRejected = async (context, token) =>
    {
        context.HttpContext.Response.StatusCode = 429;
        await context.HttpContext.Response.WriteAsync("Too Many Requests");
    };

    options.AddPolicy("TenantPolicy", context =>
    {
        var tenantResolver =
            context.RequestServices.GetRequiredService<TenantResolver>();

        var tenantId = tenantResolver.ResolveTenant();
        var limit = GetTenantLimit(tenantId);

        return RateLimitPartition.GetTokenBucketLimiter(
            tenantId,
            _ => new TokenBucketRateLimiterOptions
            {
                TokenLimit = limit,
                TokensPerPeriod = limit,
                ReplenishmentPeriod = TimeSpan.FromMinutes(1),
                AutoReplenishment = true
            });
    });
});

RateLimitPartition.GetTokenBucketLimiter(...) is the throttling engine using fully native ASP.NET Core 10.

While at the top, add the GetTenantLimit method:

static int GetTenantLimit(string tenantId)
{
    return tenantId switch
    {
        "tenantA" => 10, // Premium tenant
        "tenantB" => 5,  // Standard tenant
        _ => 2           // Default / anonymous
    };
}

We are defining the maximum request per minute for each client by extracting tenantId from the header of a request. GetTenantLimit is kept hard-coded to simplify our implementation. In real scenarios, you will use a Redis cache or database for that.

Step 6: Add controller

Our controller is as follows:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.RateLimiting;

namespace Net10RateLimiter.Controllers;

[EnableRateLimiting("TenantPolicy")]
[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    [HttpGet]
    public IEnumerable<string> Get()
        => ["Sunny", "Windy", "Breezy"];
}

The attribute [EnableRateLimiting("TenantPolicy")] associates our tenant policy with the controller.

Step 7: Enable the Middleware

Insert rate limiter middleware:

var app = builder.Build();

app.UseRateLimiter();

app.MapControllers();

app.Run();

Make sure to add this just before controllers, so it blocks the request before hitting the controller if the rate limit exceeds.

Our final Program.cs looks like this:

using System.Threading.RateLimiting;
using Net10RateLimiter.Services;

static int GetTenantLimit(string tenantId)
{
    return tenantId switch
    {
        "tenantA" => 10, // Premium tenant
        "tenantB" => 5,  // Standard tenant
        _ => 2           // Default / anonymous
    };
}

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();
builder.Services.AddControllers();
// Required for HttpContext access
builder.Services.AddHttpContextAccessor();

// Tenant resolver must be scoped
builder.Services.AddScoped<TenantResolver>();
builder.Services.AddRateLimiter(options =>
{
    options.OnRejected = async (context, token) =>
    {
        context.HttpContext.Response.StatusCode = 429;
        await context.HttpContext.Response.WriteAsync("Too Many Requests");
    };

    options.AddPolicy("TenantPolicy", context =>
    {
        var tenantResolver =
            context.RequestServices.GetRequiredService<TenantResolver>();

        var tenantId = tenantResolver.ResolveTenant();
        var limit = GetTenantLimit(tenantId);

        return RateLimitPartition.GetTokenBucketLimiter(
            tenantId,
            _ => new TokenBucketRateLimiterOptions
            {
                TokenLimit = limit,
                TokensPerPeriod = limit,
                ReplenishmentPeriod = TimeSpan.FromMinutes(1),
                AutoReplenishment = true
            });
    });
});

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

app.UseRateLimiter();

app.MapControllers();
app.Run();

And the file structure looks like this:

Step 8: Run and test

dotnet run

Let us test this in Postman. Tenant A can call the endpoint:

So can Tenant B:

Once Tenant A reached the limit

Once tenant B reached the limit, you will see the endpoint returning a status code of 429, meaning too many requests:

What has .NET 10 improved in the rate limiter?

.NET 10 has changed the game of rate limiter in many ways, such as:

• While .NET 8 introduced native rate-limiting, .NET 10 improved throttling middleware, eliminating verbose and third-party reliance. You can simply use AddRateLimiter and add UseRateLimiter to the pipeline now.
• Earlier, developers had to implement counter expiration, sliding windows, and token buckets for handling race conditions and concurrency-safe code. The practice was tiring and risky to maintain. .NET 10 flattens these jobs.
• Rate limiting was mostly IP-based with no native concept of tenants. If you had to design it for a SaaS multitenant application, you would have to do it manually. In .NET 10, partitioned rate limiters allow each tenant to have an isolated limiter, preventing noisy-neighbor issues by design.
• Scalability of rate limiting demands Redis, distributed locks, and careful atomic operations with prior .NET versions. .NET 10 relieved the pain with its optimized high concurrency ability.
• Custom logic and third-party usage in rate limiting caused extra overhead and performance penalty. .NET 10, with its allocation-efficient and optimized middleware, runs efficiently and fast.

Conclusion

.NET 10 was released in November 2025 and is supported for three years as a long-term support (LTS) release. It brings the latest version of C# with many refinements. In this blog post for our .NET 10 and C# 14 series, we discovered refinements in the rate limiter and throttling middleware. Built-in support and middleware native implementation have improved the maintainability and performance of rate limiters.

Code: https://github.com/elmahio-blog/Net10RateLimiter.git

.NET 10 is officially out, along with C# 14. Microsoft has released .NET 10 as Long-Term Support (LTS) as a successor to .NET 8. Like every version, it is not just an update but brings something new to the table. In this series, we will explore which aspects of software can be upgraded with the latest release.

Model validation is a constant performance "tax" on every request, yet it remains non-negotiable for ensuring data integrity and a good user experience. While developers once faced a trade-off between strict validation and high throughput, .NET 10 eliminates this friction. In this post, I'll examine the benchmarks to see how these shifts dramatically reduce latency in .NET 10.

APIs Model Validation Benchmarking with .NET 8 and .NET 10

To start testing the improvements, I have created a solution named ValidationBenchmarks where three projects will reside. The structure looks like this:

.NET 8 API project

The project will contain an API with a single endpoint. Let's create it.

Step 1: Create a .NET 8 project

mkdir ApiNet8
cd ApiNet8

dotnet new webapi -n ApiNet8 --framework net8.0

Step 2: Create DTO (validation target)

using System.ComponentModel.DataAnnotations;

namespace ApiNet8.Models;

public sealed class CreateDeviceRequest
{
    [Required]
    public string DeviceId { get; set; } = default!;

    [Range(-40, 85)]
    public double Temperature { get; set; }

    [Range(0, 100)]
    public int BatteryLevel { get; set; }

    [Required]
    public DateTime Timestamp { get; set; }
}

The model is a minimal representation of telemetry data where DeviceId and Timestamp are mandatory while Temperature and BatteryLevel are restricted to be in a valid range.

Step 3: Create controller

using ApiNet8.Models;
using Microsoft.AspNetCore.Mvc;

namespace ApiNet8.Controllers;

[ApiController]
[Route("devices")]
public class DevicesController : ControllerBase
{
    [HttpPost]
    public IActionResult Create(CreateDeviceRequest request)
    {
        return Ok(new { Message = "Device accepted (.NET 8)" });
    }
}

The controller contains a single POST endpoint to create a device. The method takes our model as input.

Step 4: Configure Progam.cs

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

var app = builder.Build();

app.MapControllers();
app.Run();

If you have create a MVC API before, you will see nothing different from the default template here.

.NET 10 API project

Let's create a similar project for .NET 10.

Step 1: Create a .NET 10 project

mkdir ApiNet10
cd ApiNet10

dotnet new webapi -n ApiNet10 --framework net10.0

Steps 2, 3, and 4 are exactly the same as from the .NET 8 steps.

Benchmark project

Once we have set up both target projects, we will set up a benchmark to evaluate them.

Step 1: Create the project

Our benchmark project will be a console application using the BenchmarkDotNet package.

dotnet new console -n ApiBenchmarks
cd ApiBenchmarks

Step 2: Install the BenchmarkDotNet package

dotnet add package BenchmarkDotNet

For more information about benchmarking, check out How to Monitor Your App's Performance with .NET Benchmarking.

Step 3: Add Benchmarking code

using System.Text;
using BenchmarkDotNet.Attributes;

namespace ApiBenchmarks;
[MemoryDiagnoser]
public class ValidationBenchmarks
{
    private HttpClient _client8 = default!;
    private HttpClient _client10 = default!;
    private StringContent _invalidPayload = default!;

    [GlobalSetup]
    public void Setup()
    {
        _client8 = new HttpClient
        {
            BaseAddress = new Uri("http://localhost:5008")
        };

        _client10 = new HttpClient
        {
            BaseAddress = new Uri("http://localhost:5010")
        };

        var json = """
                   {
                       "deviceId": "",
                       "temperature": 120,
                       "batteryLevel": 150,
                       "timestamp": null
                   }
                   """;

        _invalidPayload = new StringContent(
            json,
            Encoding.UTF8,
            "application/json"
        );
    }

    [Benchmark]
    public async Task Net8_Invalid_Model()
        => await _client8.PostAsync("/devices", _invalidPayload);

    [Benchmark]
    public async Task Net10_Invalid_Model()
        => await _client10.PostAsync("/devices", _invalidPayload);
}

Here, I initialized two clients, _client8 for calling the API of the .NET 8 project and _client10 to call the endpoint of the .NET 10 project. To represent an invalid payload, I created an _invalidPayload field. To test the worst case, I violated all the validations.

Step 4: Call the benchmark in Program.cs

using ApiBenchmarks;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<ValidationBenchmarks>();

Step 5: Run the projects

Open 3 terminals, on the first one run

cd ApiNet8
dotnet run --urls "http://localhost:5100"

Run the following on the Second one

cd ApiNet10
dotnet run --urls "http://localhost:5200"

While on the third one

cd ApiBenchmarks
dotnet run -c Release

So each of the API will be running on the designated port.

Result

Let's break down how .NET performed about 3x faster in several ways.

• Earlier model validation relied heavily on reflection, such as discovering attributes like [Required], [Range], and [StringLength]. Applying reflection on properties adds to the time. .NET 10 generates validation metadata at build time and replaces reflection with precomputed accessors. This actually saves a runtime check that happened earlier due to reflection.
• .NET 10 uses Span<T> where possible, and avoids LINQ in hot paths.
• Attributes executed as object-oriented (OO) components, relying on virtual method calls and object-based values in prior versions. Classes provide a flexible solution, but they were expensive to the CPU. .NET 10 precomputes validation metadata and replaces virtual, object-based execution with direct, typed method calls. That means the .NET 10 keeps validation attributes as an OO API but replaces their runtime execution with precomputed, direct calls that are cheaper for the CPU.
• During attribute invocation, expensive boxed values were used along with context objects. .NET 10 eliminated boxing for value types and introduced a shared validation context where safe.
• .NET 10 replaced repeated metadata traversal of evaluating each attribute and building ModelState entries with fewer temporary strings, lazy creation of error messages, and smarter reuse of ModelError objects. This ensured low GC pressure and better stability of latency. The provision helps in APIs where validation errors often occur, such as auth endpoints, ingestion APIs, and public APIs.
• .NET 10 has better p95 / p99 latency, less jitter, more predictable execution, fewer unpredictable branches, and less runtime metadata walking. The results are visible in StdDev, which is 3x less than its counterpart.

Conclusion

.NET 10 is released in November 2025 and is supported for three years as a long-term support (LTS) release. It brings the latest version of C# with many refinements. In the blog post for our .NET 10 and C# 14 series, I highlighted improvements to the model validations. .NET 10 has changed the nature of the validation process from reflection to precomputed, faster calls. We saw a dramatic cut down of 3x in parameters like StdDev and Error due to better p99 latency and less jittering in the latest version.

Code: https://github.com/elmahio-blog/ValidationBenchmarks

.NET 10 is officially out, along with C# 14. Microsoft has released .NET 10 as Long-Term Support (LTS) as a successor to .NET 8. Like every version, it is not just an update but brings something new to the table. In this series, we will explore which aspects of software can be upgraded with the latest release. Today, in the series of What is new in .NET 10 and C#14, we will evaluate on-ground changes in the APIs using minimal examples.

APIs don't need any introduction. From loading the cart to your mobile to showing this blog on your computer, everything is fetched by APIs. In today's dynamic websites, a simple action requires multiple API calls. So, a simple lag can hurt users' experience, no matter what application you build. .NET 10 brings some thoughtful changes for APIs. Some major improvements, like JIT inlining and lower GC burden, made things faster across operations. However, there are enhancements in API pipelining as well. Let's observe how API operations are improved in .NET 10.

Benchmarking Minimal APIs with .NET 8 and .NET 10

I have created a directory MinimalApiComparison where three projects will reside. Consider the structure:

One folder per API version and another for the benchmarks.

.NET 8 minimal API project

Let's start by creating a minimal API on .NET 8.

Step 1: Create a .NET 8 project

mkdir ApiNet8
cd ApiNet8

dotnet new webapi -n ApiNet8 --framework net8.0

Step 2: Set up the code

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/weather", () =>
{
    return new WeatherForecast(DateTime.Now, 25, "Sunny");
});

app.Run();

public record WeatherForecast(DateTime Date, int TemperatureC, string Summary);

Just a single endpoint named /weather.

.NET 10 Minimal API project

Now, let's set up a similar project for .NET 10.

Step 1: Create a .NET 10 project

mkdir ApiNet10
cd ApiNet10

dotnet new webapi -n ApiNet10 --framework net10.0

Step 2: Set up the code

var builder = WebApplication.CreateBuilder(args);

builder.Services.ConfigureHttpJsonOptions(o =>
{
    o.SerializerOptions.AllowOutOfOrderMetadataProperties = true;
});

var app = builder.Build();

app.MapGet("/weather", static () =>
    {
        return new WeatherForecast(DateTime.Now, 25, "Sunny");
    })
    .WithName("GetWeather")
    .WithSummary("Faster pipeline in .NET 10");

app.Run();

public record WeatherForecast(DateTime Date, int TemperatureC, string Summary);

The property AllowOutOfOrderMetadataProperties allows skipping strict ordering checks in JSON deserialization. It is an optimisation step that reduces parsing branches in compilation and speeds up model binding. static () => Prevents closure allocation by restricting the lambda from capturing variables. In preceding versions, lambda saves the inner variable in Gen 0 memory. While in the latest updates, static lambda results in 0 allocation and a faster, memory-efficient API.

Benchmark project

Once we set up both target projects, let us move to the benchmark to evaluate them.

Step 1: Create the project

Our benchmark project will be a console application.

dotnet new console -n ApiBenchmarks
cd ApiBenchmarks

Step 2: Install the BenchmarkDotNet package

We are using `BenchmarkDotNet to observe the results. For more information about this package, check out How to Monitor Your App's Performance with .NET Benchmarking.

dotnet add package BenchmarkDotNet

Step 3: Set up the URLs benchmarking code

using System.Net.Http.Json;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Order;

[MemoryDiagnoser]
[SimpleJob(warmupCount: 3, iterationCount: 10)]
[Orderer(SummaryOrderPolicy.FastestToSlowest)]
public class ApiComparisonBenchmarks
{
    private readonly HttpClient _client8;
    private readonly HttpClient _client10;

    public ApiComparisonBenchmarks()
    {
        _client8 = new HttpClient { BaseAddress = new Uri("http://localhost:5100") };
        _client10 = new HttpClient { BaseAddress = new Uri("http://localhost:5200") };
    }

    [Benchmark]
    public async Task WeatherNet8()
    {
        var result = await _client8.GetFromJsonAsync<WeatherForecast>("/weather");
    }

    [Benchmark]
    public async Task WeatherNet10()
    {
        var result = await _client10.GetFromJsonAsync<WeatherForecast>("/weather");
    }
}

public record WeatherForecast(DateTime Date, int TemperatureC, string Summary);

I created two methods WeatherNet8 to hit the .NET 8 minimal API and WeatherNet10 for the .NET 10 version. I have specified server URLs with each client explicitly. The [Benchmark] decorator will do the rest of the job.

Step 4: Run the projects

Open 3 terminals, on the first one run:

cd ApiNet8
dotnet run --urls "http://localhost:5100"

Run the following on the second one:

cd ApiNet10
dotnet run --urls "http://localhost:5200"

While on the third one:

cd ApiBenchmarks
dotnet run -c Release

So each of the API will be running on the designated port. ApiBenchmark hits its endpoint at /weather and performs benchmarking.

Output

We can observe a difference in the same api of both projects. .NET 10 did the job quite fast, and other parameters are also lower, indicating the performance improvements in the latest version. .NET 10 has 3x smaller Standard deviation and error due to less jitter in execution times by the grace of JIT improvements and JSON parsing novelty. Pipeline configurations like AllowOutOfOrderMetadataProperties and static () => reduced the per-request overhead. AllowOutOfOrderMetadataProperties lowers CPU burden and reduces System.Text.Json paths in compilation. And static lambda not only eliminated closure allocation but made the delegate work faster with lower Garbage Collector pressure.

Our big win was not only in the pipeline configuration but also in faster request-response improvements in ASP.NET Core. .NET 10 has optimized middleware dispatch overhead, added static pipeline analysis and faster endpoint selection, resulting in lower mean and tail latency. Our observation was just on a minimal API with small objects. These enhancements will bring noticeable results when you work on real projects with larger API operations.

Conclusion

.NET 10 is released in November 2025 and is supported for three years as a long-term support (LTS) release. For the APIs pipeline, .NET 10 brought key enhancements. In this post, I showed these enhancements with on-ground benchmark analysis. Better JIT inlining, lower CPU and GC pressure, and numerous other factors have contributed to better APIs.

Source code: https://github.com/elmahio-blog/MinimalApiComparison-.git

.NET 10 is officially out, along with C# 14. Microsoft has released .NET 10 as Long-Term Support (LTS) as a successor to .NET 8. Like every version, it is not just an update but brings something new to the table. In this series, we will explore which aspects of software can be upgraded with the latest release. Today, I will evaluate the improvements in EF Core's data fetching that .NET 10 brought.

If you are a .NET developer, you will most likely choose EF Core for database operations in your application. You are not alone, actually EF Core is a leading ORM for .NET applications due to its handy snippets and extensive features. Any data fetching operation looks easy with the ORM. However, it is not that simple under the hood. Lots of work goes into fetching the data and posting it to your application. .NET 10 made several improvements to support the process and enhance EF Core's part of the task. From JIT's better inlining to cleaner row materialization, we will calculate with benchmark the older version of the framework and the latest one.

EF Core Data fetching in .NET 8 and .NET 10

To benchmark the fetching performance, I will use a .NET 8 API and a .NET 10 API, each with the same PostgreSQL database below. To make the data size considerable, I have inserted 200000 records. Let's go through the steps for setting up the database.

Step 1: Create a PostgreSQL database

I have named the database efbench_db.

Step 2: Create the Users table and insert data

CREATE TABLE "Users" (
    "Id" SERIAL PRIMARY KEY,
    "Name" TEXT NOT NULL,
    "OrganizationId" INT NOT NULL
);

INSERT INTO "Users" ("Name", "OrganizationId")
SELECT 
    'User ' || g,
    (g % 10) + 1
FROM generate_series(1, 200_000) g;

The new table can be inspected using a bit of SQL.

For the C# code, I will create a project structure looking like this:

EF Core data access with .NET 8 and C#12

Let us start by creating the project for querying user data from .NET 8.

Step 1: Create a Web Api project in .NET 8

dotnet new webapi -n ApiNet8 -f net8.0

Step 2: Install the necessary NuGet packages

dotnet add package Microsoft.EntityFrameworkCore --version 8.*
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL --version 8.*

Here we specified package versions that will install the latest compatible version with .NET 8.

Step 3: Define the model

namespace ApiNet8.Models;

public class User
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public int OrganizationId { get; set; }
}

Step 4: Configure AppDbContext

using ApiNet8.Models;
using Microsoft.EntityFrameworkCore;

namespace ApiNet8.Data;

public class AppDbContext: DbContext
{
    public DbSet<User> Users => Set<User>();

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

Step 5: Add the connection string to appsettings.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ConnectionStrings": {
    "DefaultConnection": "Host=localhost;Port=5432;Database=efbench_db;Username=postgres;Password=pass"
  },
  "AllowedHosts": "*"
}

Step 6: Set up Program.cs

I have injected the connection string and AppDbContext in Program.cs. So our final file looks like this:

using ApiNet8.Data;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseNpgsql(connectionString);
});

var app = builder.Build();

app.MapGet("/users/{orgId:int}", async (int orgId, AppDbContext db) =>
{
    return await db.Users
        .AsNoTracking()
        .Where(u => u.OrganizationId == orgId)
        .Select(u => new { u.Id, u.Name })
        .ToListAsync();
});

app.Run();

One important thing that the Program.cs contains a minimal API to fetch users filtered by OrganizationId using a projection.

EF Core data access with .NET 10 and C#14

It is time to introduce the same code but for .NET 10.

Step 1: Create a .NET 10 API project

dotnet new webapi -n ApiNet10 -f net10.0

Step 2: Add the required packages

dotnet add package Microsoft.EntityFrameworkCore --version 10.*
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL --version 10.*

Steps 3, 4, and 5 are the same as the preceding project.

Step 6: Add configuration to Program.cs

using ApiNet10.Data;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// EF Core 10 pipeline optimizations
builder.Services.ConfigureHttpJsonOptions(o =>
{
    o.SerializerOptions.AllowOutOfOrderMetadataProperties = true;
});

// Read connection string from appsettings
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");

// Register DbContext
builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseNpgsql(connectionString);
});

var app = builder.Build();

app.MapGet("/users/{orgId:int}",
    static async (int orgId, AppDbContext db) =>
        await db.Users
            .AsNoTracking()
            .Where(u => u.OrganizationId == orgId)
            .Select(u => new { u.Id, u.Name })
            .ToListAsync()
);

app.Run();

A few noticeable differences here are allowing out-of-order metadata and static keyword in minimal API fetching, which allows skipping strict ordering checks in JSON deserialization. It is an optimisation step that reduces parsing branches in compilation and speeds up model binding. static () => Prevents closure allocation by restricting the lambda from capturing variables. In preceding versions, lambda saves the inner variable in Gen 0 memory. While in the latest updates, static lambda results in 0 allocation and a faster, memory-efficient API.

API Benchmark project

Finally, we can add our referee, the API benchmark project.

Step 1: Add a Console project to the solution

dotnet new console -n ApiBenchmarks

Step 2: Install the required NuGet packages

dotnet add package BenchmarkDotNet
dotnet add package Microsoft.Extensions.Http

Step 3: Add Benchmarking code

I added the ApiBenchmarks class.

using BenchmarkDotNet.Attributes;
using System.Net.Http.Json;

namespace DefaultNamespace;

[MemoryDiagnoser]
public class ApiBenchmarks
{
    private readonly HttpClient _net8 =
        new() { BaseAddress = new Uri("http://localhost:5267") };

    private readonly HttpClient _net10 =
        new() { BaseAddress = new Uri("http://localhost:5186") };

    [Benchmark]
    public async Task Net8_EFCore8()
    {
        await _net8.GetFromJsonAsync<object[]>("/users/5");
    }

    [Benchmark]
    public async Task Net10_EFCore10()
    {
        await _net10.GetFromJsonAsync<object[]>("/users/5");
    }
}

Dedicated HTTP clients will call the endpoint of the respective project. While the [Benchmark] attribute evaluates performance on each method.

Step 4: Set up Program.cs

using BenchmarkDotNet.Running;

BenchmarkRunner.Run<ApiBenchmarks>();

Here, I call the BenchmarkRunner.Run method to run the tests.

Step 5: Run the projects

Open 3 terminals, on the first one run

cd ApiNet8
dotnet run --project Api.Net8

On the second

cd ApiNet10
dotnet run --project Api.Net10

On the final terminal

cd ApiBenchmarks
dotnet run -c Release

Output

.NET 10 performance is 25 to 50% better in the benchmark metrics. Although query and EF Core are the same, the impact is due to .NET 10's execution speedup. Some vital reasons behind this improvement are

• JIT inlines methods and optimizes escape analysis better. .NET 10 performs fast dictionary and span operations. They flattened the pipeline, eliminating unpredictable branches in hot paths. Hence EF Core does not dangle in these complexities.
• .NET 10 brought faster ExpressionVisitorand caching of traversal results. Previously, EF Core had to walk expression trees multiple times and allocate helper objects. Now your code has a single-pass expression analysis and fewer allocations.
• One big blow is in Row Materialization that involves EF Cores data reading from the source to mapping in the .NET object. EF Core goes through multiple abstraction layers, reads columns defensively to handle null values and conversion checks, traverses additional branches for entity tracking, and generic materializers. .NET 10's inlining straightened the materialization flow, applied stronger devirtualization, upgraded nullable checks so EF Core can skip redundant null checks safely. Faster generic specialization made value handling cheaper.
• JIT optimization of the hot path helped EF Core run without regression, saving decisive time.

Conclusion

.NET 10 is released in November 2025 and is supported for three years as a long-term support (LTS) release. It brings the latest version of C# with many refinements. In the blog post for our .NET 10 and C# 14 series, I visualized with benchmarked the impact of .NET 10 improvements on EF Core data fetching. .NET 10's game-changer enhancements are its JIT inlining optimizations and request pipeline streamlining that massively impacted every feature. Same worked with EF Core's data fetching, along with other icebreakers that I discussed.

Code: https://github.com/elmahio-blog/EfCoreBenchmarkDemo.git

.NET 10 is officially out, along with C# 14. Microsoft has released .NET 10 as Long-Term Support (LTS) as a successor to .NET 8. Like every version, it is not just an update but brings something new to the table. In this series, we will explore which aspects of software can be upgraded with the latest release. Today, in the series of What is new in .NET 10 and C#14, we will see optimization in log aggregation jobs.

Logging is a pathway to find anomalies and debug issues in any application. The application keeps generating logs for operations such as receiving device data, calling an API, checking background services, and more. Processing of logs requires high throughput because some applications demand the generation of multiple logs for a single operation. That job adds up once you do aggregation, including normalizing, parsing to the desired format, and storing them. Notification services often analyze stored logs to generate notifications and alerts based on the criticality of the logs. So, log aggregation is a tedious job for the server and a silent soldier of the application. Mindful of these, .NET brings several refinements in its JSON and string operations. Besides memory allocation, changes will help you in log generation. I will shed light on how much the said task has been improved.

Log Aggregation job with .NET 8 and C#12

To observe a significant improvement in .NET 10, let's first create log aggregation with the prior version, .NET 8.

Step 1: Create a project

Run the command to create a log aggregation project

mkdir LogBenchmark.Net8
cd LogBenchmark.Net8

Step 2: Install Benchmark and Newtonsoft NuGet packages

dotnet add package BenchmarkDotNet
dotnet add package Newtonsoft.Json

We will use BenchmarkDotNet to measure the time taken for each method.

Step 3: Write Logging jobs with benchmark

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using Newtonsoft.Json.Linq;
using System.Text.Json;

BenchmarkRunner.Run<LogBenchmark>();

[MemoryDiagnoser]
public class LogBenchmark
{
    private readonly byte[] _utf8LogBytes;
    private readonly string _logString;

    public LogBenchmark()
    {
        _logString = """
        {
            "level": "info",
            "deviceId": "A1B2C3D4E5F60788",
            "timestamp": "2025-12-01T10:22:00Z",
            "message": "Temperature reading received",
            "value": 22.5
        }
        """;

        _utf8LogBytes = System.Text.Encoding.UTF8.GetBytes(_logString);
    }

    // ------------------------------------------------------------
    // 1. Baseline: Newtonsoft.Json 
    // ------------------------------------------------------------
    [Benchmark(Baseline = true)]
    public string Newtonsoft_Parse()
    {
        var obj = JObject.Parse(_logString);
        return (string)obj["deviceId"]!;
    }

    // ------------------------------------------------------------
    // 2. System.Text.Json in UTF-16 
    // ------------------------------------------------------------
    [Benchmark]
    public string SystemTextJson_Parse()
    {
        using var doc = JsonDocument.Parse(_logString);
        return doc.RootElement.GetProperty("deviceId").GetString()!;
    }

    // ------------------------------------------------------------
    // 3. UTF8JsonReader + Span<byte> 
    // ------------------------------------------------------------
    [Benchmark]
    public string? Utf8JsonReader_Parse()
    {
        var reader = new Utf8JsonReader(_utf8LogBytes);

        while (reader.Read())
        {
            if (reader.TokenType == JsonTokenType.PropertyName &&
                reader.ValueTextEquals("deviceId"))
            {
                reader.Read();
                return reader.GetString();
            }
        }

        return null;
    }
}

I defined 3 methods for logging using NewtonSoft and System.Text and Utf8Json returning deviceId. Each of them is decorated with the Benchmark attribute. To test, I defined a log message in the constructor.

Step 4: Run and test

As we know, we have to run a release in benchmark projects.

dotnet run -c Release

Log Aggregation job with .NET 10 and C#14

Now jump to our latest tool, the .NET 10. I will create the same project

Step 1: Create a project

mkdir LogBenchmark.Net10
cd LogBenchmark.Net10

Step 2: Install Benchmark and Newtonsoft NuGet packages

dotnet add package BenchmarkDotNet
dotnet add package Newtonsoft.Json

Step 3: Write Logging jobs with benchmark

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using Newtonsoft.Json.Linq;
using System.Text.Json;

BenchmarkRunner.Run<LogBenchmark>();

[MemoryDiagnoser]
public class LogBenchmark
{
    private readonly byte[] _utf8LogBytes;
    private readonly string _logString;

    public LogBenchmark()
    {
        _logString = """
        {
            "level": "info",
            "deviceId": "A1B2C3D4E5F60788",
            "timestamp": "2025-12-01T10:22:00Z",
            "message": "Temperature reading received",
            "value": 22.5
        }
        """;

        _utf8LogBytes = System.Text.Encoding.UTF8.GetBytes(_logString);
    }

    // ------------------------------------------------------------
    // 1. Baseline: Newtonsoft.Json 
    // ------------------------------------------------------------
    [Benchmark(Baseline = true)]
    public string Newtonsoft_Parse()
    {
        var obj = JObject.Parse(_logString);
        return (string)obj["deviceId"]!;
    }

    // ------------------------------------------------------------
    // 2. System.Text.Json in UTF-16 
    // ------------------------------------------------------------
    [Benchmark]
    public string SystemTextJson_Parse()
    {
        using var doc = JsonDocument.Parse(_logString);
        return doc.RootElement.GetProperty("deviceId").GetString()!;
    }

    // ------------------------------------------------------------
    // 3. UTF8JsonReader + Span<byte> 
    // ------------------------------------------------------------
    [Benchmark]
    public string? Utf8JsonReader_Parse()
    {
        var reader = new Utf8JsonReader(_utf8LogBytes);

        while (reader.Read())
        {
            if (reader.TokenType == JsonTokenType.PropertyName &&
                reader.ValueTextEquals("deviceId"))
            {
                reader.Read();
                return reader.GetString();
            }
        }

        return null;
    }
}

So, to keep the scale equal, I have used the same code for all 3 methods with the same input message.

Step 4: Run and test

Running the project

dotnet run -c Release

We can observe the clear difference between the two versions. .NET 10 improved logging and string operations significantly. Our latest fellow reduced execution time up to 38%. Let's break down what made .NET 10 achieve the feat

• JIT optimizes Span<T> and Utf8JsonReader in the area of escape analysis. It reduced object allocation and reduced Gen0 Garbage Collector (GC) activity. JIT also inlines small methods, Utf8JsonReaderresulting in fewer loops.
• UTF-8 processing also saw improvements, including faster UTF-8 transcoding, reduced branching on common code paths, and faster byte scanning.
• The JIT compiler can place the promoted members of struct arguments into shared registers directly, rather than on the stack, eliminating unnecessary memory operations.
• .NET team is working to upgrade System. Text is Microsoft's own string manipulation library. System.Text that is native to .NET, as opposed to Newtonsoft, which is third-party. They improved property lookup, UTF-8 parsing, and JSONDocument memory usage in the updates.
• Although NewtonSoft is not managed by Microsoft, compiler enhancements affected the application's overall performance. We saw that in our results, too. Lower GC pauses, better dictionary lookups, faster JIT inlining, and improved string allocation helped Newtonsoft perform well.

Conclusion

.NET 10 is released in November 2025 and is supported for three years as a long-term support (LTS) release. It brings the latest version of C# with many refinements. In the blog post for our .NET 10 and C# 14 series, I highlighted improvements to the log aggregation jobs. Numerous changes to GC operations, JIT, and string manipulation have yielded significant results, as I demonstrated through benchmarking comparing predecessor .NET 8.

.NET 8 example: https://github.com/elmahio-blog/LogBenchmark.Net8

.NET 10 example: https://github.com/elmahio-blog/LogBenchmark.Net10

Selection logic is a prominent part of many applications. Whether you add a simple environment toggle, a UI mode decision, or apply a discount, you have to rely on user input. Sometimes, simply using an intuitive if-else or a switch case can work. However, when conditions are growing or a complex algorithm selection is required, simple conditional statements can't work. Your code becomes exhaustive and hard to maintain. The Strategy pattern rescues the situation, adheres to the open/closed principle, and keeps the logic maintainable. This article walks you through a practical, straightforward example of the strategy pattern: choosing between Regular, VIP, and Student discount strategies at runtime.

What is the Strategy pattern?

The Strategy design pattern is a behavioral pattern used when you need to switch between different algorithms at runtime. The strategy pattern encapsulates algorithms and selects the right one when needed, usually based on an input. This pattern provides a flexible, maintainable solution to an algorithm-selection problem, keeping the code cleaner and easier to extend. If you need to add a new algorithm, just add another class instead of touching the existing logic, adhering to the open/closed principle.

What is the problem without the Strategy pattern?

To understand the usability of the strategy pattern, we need to identify the problems we may face without it. Suppose we offer different discounts to different users based on their membership. A naive solution is to use an if-else statement or a switch case. Let's do it and evaluate the implementation.

Step 1: Create a Console application

dotnet new console -n StrategyPatternDemo
cd StrategyPatternDemo

Step 2: Create DiscountService class

In the service, we will define discount calculation with a conditional statement.

public class DiscountService
{
    public decimal GetDiscount(string customerType, decimal amount)
    {
        if (customerType.ToLower() == "regular")
        {
            return amount * 0.05m;
        }
        else if (customerType.ToLower() == "vip")
        {
            return amount * 0.20m;
        }
        else
        {
            return 0;
        }
    }
}

Step 3: Use the service in the Strategy Pattern Sword.cs

using StrategyPatternDemo;

Console.Write("Enter customer type (regular/vip): ");
var type = Console.ReadLine();

Console.Write("Enter amount: ");
var amount = decimal.Parse(Console.ReadLine());

var service = new DiscountService();
var discount = service.GetDiscount(type, amount);
var final = amount - discount;

Console.WriteLine($"Discount: {discount}");
Console.WriteLine($"Final Price: {final}");

Step 4: Run and test

Let's test it

dotnet run

Output

It works as expected. But the code contains design and maintainability flaws.

• The solution violates the Open/Closed principle. Adding a new membership will require changes to the core method, such as adding an else-if block.
• All the discount logic is tightly coupled in a single class and lacks separation of concerns or single responsibility.
• Conjoined code makes testing harder. To ensure the functionality, you have to test the monster every time.
• As the conditions grow, you can fall into a spiral of conditions. Imagine if you have 20 memberships, that will be a nightmare for maintainability.

Implementing the strategy pattern in a console application

In our example, let's address the above issues using the Strategy Pattern.

Step 1: Define Strategy Interface

Adding the discount strategy interface

public interface IDiscountStrategy
{
    decimal ApplyDiscount(decimal amount);
}

Step 2: Add concrete strategies

Adding separate implementations of each algorithm

public class RegularDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal amount) => amount * 0.05m;
}

For Vip

public class VipDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal amount) => amount * 0.20m;
}

Notice that none of the strategies implement validation or error handling. In real-world code, you would probably want to look into that. This part has been left out of this post since the focus is around splitting the business logic out in strategies.

Step 3: Define context class

public class DiscountService
{
    private readonly IDiscountStrategy _strategy;

    public DiscountService(IDiscountStrategy strategy)
    {
        _strategy = strategy;
    }

    public decimal GetDiscount(decimal amount) => _strategy.ApplyDiscount(amount);
}

The Context class in the strategy pattern holds a reference to a strategy interface (IDiscountStrategy in our case). It receives a strategy from outside. It does not implement logic itself, instead, it delegates work to the strategy, while the concrete classes define their logic.

Step 4: Use the strategy in the Program.cs

Console.WriteLine("Enter customer type (regular/vip): ");
string type = Console.ReadLine()?.ToLower();

IDiscountStrategy strategy;

// Manually picking strategy — no switch needed, but you *can* if you want.
if (type == "vip")
    strategy = new VipDiscount();
else
    strategy = new RegularDiscount();

var service = new DiscountService(strategy);

Console.Write("Enter amount: ");
decimal amount = decimal.Parse(Console.ReadLine());

var discount = service.GetDiscount(amount);
var finalPrice = amount - discount;

Console.WriteLine($"Discount applied: {discount}");
Console.WriteLine($"Final price: {finalPrice}");

Output

We understand basic principles of the strategy pattern. We can proceed with our primary target: implementing the strategy pattern in ASP.NET Core.

Implementing the strategy pattern in an ASP.NET Core API

Step 1: Create a .NET Core api

Run the following command in the terminal

dotnet new webapi -n StrategyPatternApi
cd StrategyPatternApi

Step 2: Add concrete strategies

Adding separate implementations of each algorithm

public class RegularDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal amount) => amount * 0.05m;
}

For Vip

public class VipDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal amount) => amount * 0.20m;
}

Step 3: Define context class

public class DiscountService
{
    private readonly Func<string, IDiscountStrategy> _strategyFactory;

    public DiscountService(Func<string, IDiscountStrategy> strategyFactory)
    {
        _strategyFactory = strategyFactory;
    }

    // public API: ask for a discount by customer type
    public decimal GetDiscount(string customerType, decimal amount)
    {
        var strategy = _strategyFactory(customerType);
        return strategy.ApplyDiscount(amount);
    }
}

DiscountService plays the context role in the strategy pattern. DiscountService has a property Func<string, IDiscountStrategy> _strategyFactory that holds a factory delegate. The Func delegate returns an appropriate implementation of IDiscountStrategy based on the given type. Func allows the service to request a strategy at runtime by name/key without knowing the DI container internals or concrete types.

Step 4: Add a controller with the endpoint

[ApiController]
[Route("api/[controller]")]
public class PricingController : ControllerBase
{
    private readonly DiscountService _pricingService;

    public PricingController(DiscountService pricingService)
    {
        _pricingService = pricingService;
    }

    [HttpGet]
    public IActionResult Get([FromQuery] string type, [FromQuery] decimal amount)
    {
        var discount = _pricingService.GetDiscount(type, amount);
        var final = amount - discount;
        return Ok(new { type = type ?? "regular", amount, discount, final });
    }
}

Step 5: Configure Program.cs

Add the concrete services in dependency injection (DI) in the Program.cs file

services.AddTransient<RegularDiscount>();
services.AddTransient<VipDiscount>();

They are transient because discount strategies are stateless, so creating a new instance each time is fine. Note that I haven't injected them with IDiscountStrategy any implementing service because ASP.NET Core decides this automatically. Hence, the final code will look like this:

using StrategyPatternApi;

var builder = WebApplication.CreateBuilder(args);
var services = builder.Services;

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Register concrete strategy types so they can be resolved by the factory
services.AddTransient<RegularDiscount>();
services.AddTransient<VipDiscount>();

services.AddSingleton<Func<string, IDiscountStrategy>>(sp => key =>
{
    var k = (key ?? "").Trim().ToLowerInvariant();
    return k switch
    {
        "vip" => sp.GetRequiredService<VipDiscount>(),
        // add more cases if you add more strategies
        _ => sp.GetRequiredService<RegularDiscount>()
    };
});

// Register the service that uses the factory
services.AddScoped<DiscountService>();

// Add controllers (or leave for minimal endpoints)
services.AddControllers();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}
app.MapControllers();
app.Run();

In DI, the decisive part is:

services.AddSingleton<Func<string, IDiscountStrategy>>(sp => key =>
{
    var k = (key ?? "").Trim().ToLowerInvariant();
    return k switch
    {
        "vip" => sp.GetRequiredService<VipDiscount>(),
        // add more cases if you add more strategies
        _ => sp.GetRequiredService<RegularDiscount>()
    };
});

As explicitly stated, the switch condition resolves the appropriate concrete strategy via DI based on the type value. If any condition does not match, I made a default choice to get RegularService.

Step 6: Run and test

dotnet run

Now running the project

Extension of algorithms in the ASP.NET Core strategy pattern

The Open/Close principle is one of the benefits of the Strategy Pattern. Let's continue with our example of how we can add a new discount within the bounds of the Open/Close principle.

Step 1: Add the Student discount's concrete strategy

public class StudentDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal amount) => amount * 0.10m;
}

Step 2: Register a new service

services.AddTransient<StudentDiscount>();

Step 3: Update factory switch

services.AddSingleton<Func<string, IDiscountStrategy>>(sp => key =>
{
    var k = (key ?? "").Trim().ToLowerInvariant();
    return k switch
    {
        "vip" => sp.GetRequiredService<VipDiscount>(),
        "student" => sp.GetRequiredService<StudentDiscount>(),   
        _ => sp.GetRequiredService<RegularDiscount>()
    };
});

To add a new strategy implementation, we simply need to add the strategy code and inject it via dynamic DI.

Step 4: Run and test

dotnet run

By default value

Conclusion

Writing long if-else or cases is tiring. Every time you need to add a condition, you have to dive into the well and add one condition. The same happens while debugging. The strategy pattern provides a modular solution that keeps the code intact while dynamically allowing you to extend conditions. In this blog post, I highlighted the need for a strategy pattern and showed how to implement it in an ASP.NET Core API.

Example 1: https://github.com/elmahio-blog/StrategyPatternDemo

Example 2: https://github.com/elmahio-blog/StrategyPatternApi

Not all data in your application should live as a standalone table with its own ID and lifecycle. Sometimes you need a tightly coupled dependent object that exists alongside its parent, like a movie's budget, a survey's questions, or a customer's address. If you had the magic to handle this data differently, you could save tons of lines and reduce Entity Framework Core (EF Core) overhead. The good news is that EF Core offers owned entities that do this. It reduces the complexities of your domain model. In this post, I will show you how to use owned entity types to maintain dependent data.

What is an owned entity?

In EF Core, an owned entity is a special type of entity that exists only within another entity and cannot stand alone in the database. Unlike other EF models, owned entities do not have their own identity, such as a primary key. Owned entities inherit the identity of their parent table. The lifecycle of owned entities also depends on the parent entity. When the owning entity is created, owned properties are made, when it is deleted, all of its owned properties are also deleted.

Key characteristics of EF Core's owned properties

EF Core owned entities possess the following characteristics:

• Owned entity types do not have a separate identity. Instead, they depend on their parents' identity.
• An owned entity's lifecycle is tied to its owner entity and cannot exist independently of it. It is created, updated, and deleted with its parent entity.
• They are stored in the same table as their owner by default. Although we create a separate class for them, they do not go to a separate table and are saved with their class prefix, like Address_Street.
• An owned entity does not have a separate DbSets and cannot be queried independently.
• An owned entity always has a one-to-one relation with its owner entity
• You cannot reference an owned entity with another entity via a foreign key relation.
• EF change tracker tracks owned entities along with their owners, not as separate entities.
• Can encapsulate complex data types such as coordinates, addresses, and contact details.

How to use an owned entity in EF Core

I am creating a console application to see how we can implement an owned entity in an EF Core-based project.

Step 1: Create a console application

Run the following in the CLI

dotnet new console -o MovieProjectionDemo

Step 2: Install all required packages

For the project, we need to run the command to install the required NuGet packages.

dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.Extensions.Configuration
dotnet add package Microsoft.Extensions.Configuration.Json

I will be using a Postgres database, so installing Npgsql.EntityFrameworkCore.PostgreSQL You can install the NuGet package accordingly, as per your preferred database.

Step 3: Add models

namespace OwnedEntityDemo.Models;

public class Movie
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;
    public int ReleaseYear { get; set; }
    public string Genre { get; set; } = string.Empty;
    
    public Budget Budget { get; set; } = null!;
}

public class Budget
{
    public decimal ProductionCost { get; set; }
    public decimal MarketingCost { get; set; }
    public decimal DistributionCost { get; set; }
    public string Currency { get; set; } = string.Empty;
}

Here, the Budget object will be part of the Movie entity. Note, I did not create any ID in the budget as it relies on its owner, the Movie entity.

Step 4: Set up the DbContext

using Microsoft.Extensions.Configuration;
using OwnedEntityDemo.Models;
using Microsoft.EntityFrameworkCore;

namespace OwnedEntityDemo;

public class AppDbContext: DbContext
{
    public DbSet<Movie> Movies => Set<Movie>();

    private readonly string _connectionString;

    public AppDbContext()
    {
        // Simple reading from appsettings.json
        var config = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("appsettings.json")
            .Build();

        _connectionString = config.GetConnectionString("PostgresConnection");
    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseNpgsql(_connectionString);
        
    }
    
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Movie>()
            .OwnsOne(c => c.Budget, bugdet =>
            {
                bugdet.Property(a => a.ProductionCost);
                bugdet.Property(a => a.DistributionCost);
                bugdet.Property(a => a.MarketingCost);
                bugdet.Property(a => a.Currency);
            });
    }
}

One DbSet is registered. Also, you need to configure the Budget entity as an owned entity with OwnsOne in the OnModelCreating method.

Step 5: Create appsettings.json

The console app does not contain an appsettings file by default. So I have created one with the connection string:

{
  "ConnectionStrings": {
    "PostgresConnection": "Host=localhost;Port=5432;Database=tvDb;Username=postgres;Password=4567"
  }
}

Step 6: Configure appsettings in csproj

By default, a console app will expect the file in the bin directory. To read newly added appsettings from the root directory, add the following inside the <Project> tag of the application's project file:

<ItemGroup>
  <None Update="appsettings.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

Step 7: Prepare the database

To create the table in the database, create and run the migration:

dotnet ef migrations add InitialCreate

dotnet ef database update

Our database is now ready

Notice how columns of owned entities are named as a prefix of the owned class name.

Step 8: Prepare Program.cs to write the data

We will seed the data by initializing it in the Program.cs file:

using Microsoft.EntityFrameworkCore;
using OwnedEntityDemo;
using OwnedEntityDemo.Models;

using var context = new AppDbContext();

// Make sure database exists
await context.Database.EnsureCreatedAsync();

// Add a movie with budget
var movie1 = new Movie
{
    Title = "Inception",
    Genre = "Sci-Fi",
    ReleaseYear = 2010,
    Budget = new Budget
    {
        ProductionCost = 160_000_000,
        MarketingCost = 100_000_000,
        DistributionCost = 50_000_000,
        Currency = "USD"
    }
};
var movie2 = new Movie
{
    Title = "Memento",
    Genre = "Thriller",
    ReleaseYear = 2000,
    Budget = new Budget
    {
        ProductionCost = 90_000_000,
        MarketingCost = 120_000_000,
        DistributionCost = 2_000_000,
        Currency = "USD"
    }
};

context.Movies.Add(movie1);
context.Movies.Add(movie2);
await context.SaveChangesAsync();
Console.WriteLine("Movie saved!");

// Query movie
var storedMovies = await context.Movies.ToListAsync();
foreach (var movie in storedMovies)
{
    Console.WriteLine($"Movie: {movie.Title}, Total Budget: {movie.Budget.ProductionCost + movie.Budget.MarketingCost}");
}

In the first part, we are populating the Movie table with some data. While the latter part gets and prints them. I focused on implementing the owned entity. You can query the records better with a projection.

Step 9: Run the project

Let's run it:

dotnet run

The above approach can be more customized. You can rename the column in the configuration as you want.

modelBuilder.Entity<Movie>(entity =>
{
    entity.OwnsOne(m => m.Budget, budget =>
    {
        // Optional: Configure column names
        budget.Property(b => b.ProductionCost).HasColumnName("ProductionCost");
        budget.Property(b => b.MarketingCost).HasColumnName("MarketingCost");
        budget.Property(b => b.DistributionCost).HasColumnName("DistributionCost");
        budget.Property(b => b.Currency).HasColumnName("Currency");
    });
});

That way, the columns will be like PodcutionCost and MarketingCost instead of Budget_PodcutionCost and Budget_MarketingCost.

How to add nested owned entities in EF Core

An entity can have more than one owned entity. Also, you can define a nested owned entity, an owned entity inside another owned entity. Let's have a look at how we can do that with the same example.

Step 1: Add another owned entity

Create the class CostBreakdown:

public class Budget
{
    public decimal ProductionCost { get; set; }
    public decimal MarketingCost { get; set; }
    public decimal DistributionCost { get; set; }
    public string Currency { get; set; } = string.Empty;
    public CostBreakdown Breakdown { get; set; } = null!;
}

public class CostBreakdown
{
    public decimal CastSalaries { get; set; }
    public decimal CrewSalaries { get; set; }
    public decimal Equipment { get; set; }
    public decimal CGI { get; set; }
}

Step 2: Configure a new owned type

modelBuilder.Entity<Movie>(movie =>
{
    movie.OwnsOne(m => m.Budget, budget =>
    {
        budget.Property(b => b.ProductionCost);
        budget.Property(b => b.MarketingCost);
        budget.Property(b => b.DistributionCost);
        budget.Property(b => b.Currency);

        // Nested Owned Entity
        budget.OwnsOne(b => b.Breakdown, breakdown =>
        {
            breakdown.Property(p => p.CastSalaries);
            breakdown.Property(p => p.CrewSalaries);
            breakdown.Property(p => p.Equipment);
            breakdown.Property(p => p.CGI);
        });
    });
});

As in the example, you can use the fluent API to add nested owned types to relations in your Movies table.

Step 3: Add migration

Add a new migration by running the command:

dotnet ef migrations add CostBreakdownAdded

and apply it:

dotnet ef database update

How to add a Collection Owned Entity in EF Core

Owned types can be a collection as well, where multiple objects of the same type depend on a single owner entity. In that case, EF Core maintains a separate table to save the dependent data. Let's see how we can do in our example.

Step 1: Create models

Let's create a new Questionnaire model. All the questions will be collected from the entity in question. Question.

public class Questionnaire
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;

    public List<Question> Questions { get; set; } = new();
}

public class Question
{
    public string Text { get; set; } = string.Empty;
    public string Type { get; set; } = string.Empty;  // e.g. Text, MCQ, Rating
    public bool IsRequired { get; set; }
}

Step 2: Perform configurations in the DbContext

Add a new DbSet:

public DbSet<Questionnaire> Questionnaires => Set<Questionnaire>();

and use the fluent API to set up the entity:

modelBuilder.Entity<Questionnaire>(q =>
{
    q.OwnsMany(x => x.Questions, questions =>
    {
        questions.WithOwner().HasForeignKey("QuestionnaireId");

        questions.Property<int>("Id");           // shadow key
        questions.HasKey("Id");

        questions.Property(x => x.Text).HasColumnName("Text");
        questions.Property(x => x.Type).HasColumnName("Type");
        questions.Property(x => x.IsRequired).HasColumnName("IsRequired");

        questions.ToTable("QuestionnaireQuestions"); // optional
    });
});

OwnsMany configures that each entity of Questionnaire will hold a collection of Questions as an owned type. questions.WithOwner().HasForeignKey("QuestionnaireId"); defines that each Question belongs to one Questionnaire with a foreign key QuestionnaireId. EF Core will translate it to:

QuestionnaireId INTEGER NOT NULL

Although Questions have a primary and foreign key, they are not queryable and cannot exist independently.

Step 3: Run migration

Make the updates with a new migration:

dotnet ef migrations add QuestionaireAdded

And run the migration:

dotnet ef database update

Step 4: Set up Program.cs to insert data

var survey = new Questionnaire
{
    Title = "Customer Satisfaction Survey",
    Questions = new List<Question>
    {
        new Question { Text = "How satisfied are you?", Type = "Rating", IsRequired = true },
        new Question { Text = "What can we improve?", Type = "Text", IsRequired = false },
        new Question { Text = "Would you recommend us?", Type = "YesNo", IsRequired = true }
    }
};
context.Questionnaires.Add(survey);
await context.SaveChangesAsync();
Console.WriteLine("Data saved!");

var data = await context.Questionnaires.FirstAsync();
Console.WriteLine($"Questionaire: {data.Title}");
foreach (var item in data.Questions)
{
    Console.WriteLine($"Text: {item.Text}, Type: {item.Type}");
}

Step 5: Test the project

Advantages of an owned entity

• An owned entity is a value object defined solely by its values, without an identity. The nature of owned types allows your domain to model real-world concepts while remaining clean and expressive.
• As owned entities are dependent, they cascade automatically with the owner. Hence, you do not require involvement in additional management for dependent fields, such as the questions in a questionnaire.
• In the model, you can encapsulate related fields in separate classes, while the database does not need to map them to the tables. That way, you can keep code flexible without cluttering up extra tables or DbSets.
• As EF Core stores the properties of owned entities in the same table, no additional joins are performed when querying the data. Hence, owning property helps improve the overall performance of the application.e
• Owned handles parent-child relations cleanly with shadow keys. You don't need standalone entities even for one-to-many parent-child relationships.
• Owned entities eliminate unnecessary IDs and primary keys by directly attaching them to their parent entities.
• It keeps data consistent because the lifecycle of owned entities is tied to the owner, deleting or updating the owner changes the child entities.
• The dependent entities reduce EF Core's overhead by allowing it to track only the parent entity.

Conclusion

Owned entity types provide a clean way to save complex values in the database. They are dependent entities that do not hold any identity or table of their own but exist alongside their parent. We delved into this remarkable feature and saw how you can encapsulate complex data such as addresses, costs, and order items. Owned entities keep the domain models clean by clustering related fields into dependent types.