Remigiusz Zalewski

EF Core Database First: Scaffold a DB Context from an Existing Database

Remigiusz Zalewski — Sat, 11 Apr 2026 06:01:25 GMT

Introduction

Most tutorials start with a fresh database that you design yourself. But in the real world, you inherit databases. Legacy systems, shared enterprise databases, third-party schemas - they’re everywhere, and you need to integrate your .NET Web API with them fast.

The EF Core Database First approach with scaffolding is exactly the tool for this. One command generates your DbContext and all entity models - with relationships, configurations, and Fluent API mappings - directly from the existing database schema.

In this post you’ll see the full workflow: from setting up a new .NET Web API, running the scaffold command against a real SQL Server database, understanding what gets generated and why, cleaning up the output, and wiring everything into your app properly.

🎬 Watch the full video here:

The Starting Point: An Existing Database

For this demo, the target is an ECommerceDB SQL Server database with multiple tables, foreign key relationships, and a realistic data model - orders, customers, products, categories, order details, and shippings.

The database gets created and seeded upfront using two SQL scripts run directly in SSMS. Once the data is in place, the goal is to integrate this schema into a .NET Web API without writing a single entity class by hand.

Required NuGet Packages

Before running the scaffold command, three NuGet packages need to be added to your project:

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

Tools - provides the EF Core CLI commands
Design - required at design time for scaffolding and migrations
SqlServer - the database provider for Microsoft SQL Server

The Scaffold Command

With packages in place, run this single command to generate everything:

dotnet ef dbcontext scaffold \
  "Server=localhost,1433;Database=ECommerceDB;User Id=sa;Password=YourPassword1!;TrustServerCertificate=True" \
  Microsoft.EntityFrameworkCore.SqlServer \
  --output-dir Entities

The first argument is the full connection string to your existing database
Microsoft.EntityFrameworkCore.SqlServer is the provider
--output-dir Entities places all generated files into an Entities folder

Understanding the Generated DbContext

This is what EF Core actually generates for the ECommerceDB schema. Read through it carefully - every section tells you something important about your database.

using Microsoft.EntityFrameworkCore;

namespace ECommerceAPI.Entities;

public partial class ECommerceDbContext : DbContext
{
    public ECommerceDbContext()
    {
    }

    public ECommerceDbContext(DbContextOptions options)
        : base(options)
    {
    }

    public virtual DbSet Categories { get; set; }
    public virtual DbSet Customers { get; set; }
    public virtual DbSet Orders { get; set; }
    public virtual DbSet OrderDetails { get; set; }
    public virtual DbSet Products { get; set; }
    public virtual DbSet Shippings { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        // WARNING: Move this connection string to appsettings.json
        optionsBuilder.UseSqlServer(
            "Server=localhost,1433;Database=ECommerceDB;User Id=sa;Password=YourPassword1!;TrustServerCertificate=True");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__Categori__3214EC07...");

            entity.Property(e => e.Name)
                .IsRequired()
                .HasMaxLength(100)
                .IsUnicode(false);
        });

        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__Customer__3214EC07...");

            entity.Property(e => e.FirstName)
                .IsRequired()
                .HasMaxLength(100)
                .IsUnicode(false);
            entity.Property(e => e.LastName)
                .IsRequired()
                .HasMaxLength(100)
                .IsUnicode(false);
            entity.Property(e => e.Email)
                .IsRequired()
                .HasMaxLength(200)
                .IsUnicode(false);
        });

        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__Orders__3214EC07...");

            entity.Property(e => e.OrderDate).HasColumnType("datetime");
            entity.Property(e => e.TotalAmount).HasColumnType("decimal(18,2)");
            entity.Property(e => e.Status)
                .HasMaxLength(50)
                .IsUnicode(false);

            entity.HasOne(d => d.Customer)
                .WithMany(p => p.Orders)
                .HasForeignKey(d => d.CustomerId)
                .OnDelete(DeleteBehavior.ClientSetNull)
                .HasConstraintName("FK_Orders_Customers");
        });

        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__OrderDet__3214EC07...");

            entity.Property(e => e.UnitPrice).HasColumnType("decimal(18,2)");

            entity.HasOne(d => d.Order)
                .WithMany(p => p.OrderDetails)
                .HasForeignKey(d => d.OrderId)
                .OnDelete(DeleteBehavior.ClientSetNull)
                .HasConstraintName("FK_OrderDetails_Orders");

            entity.HasOne(d => d.Product)
                .WithMany(p => p.OrderDetails)
                .HasForeignKey(d => d.ProductId)
                .OnDelete(DeleteBehavior.ClientSetNull)
                .HasConstraintName("FK_OrderDetails_Products");
        });

        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__Products__3214EC07...");

            entity.Property(e => e.ProductName)
                .IsRequired()
                .HasMaxLength(200)
                .IsUnicode(false);
            entity.Property(e => e.Price).HasColumnType("decimal(18,2)");

            entity.HasOne(d => d.Category)
                .WithMany(p => p.Products)
                .HasForeignKey(d => d.CategoryId)
                .OnDelete(DeleteBehavior.ClientSetNull)
                .HasConstraintName("FK_Products_Categories");
        });

        modelBuilder.Entity(entity =>
        {
            entity.HasKey(e => e.Id).HasName("PK__Shipping__3214EC07...");

            entity.Property(e => e.ShippedDate).HasColumnType("datetime");
            entity.Property(e => e.Address)
                .HasMaxLength(300)
                .IsUnicode(false);
            entity.Property(e => e.Status)
                .HasMaxLength(50)
                .IsUnicode(false);

            entity.HasOne(d => d.Order)
                .WithMany(p => p.Shippings)
                .HasForeignKey(d => d.OrderId)
                .OnDelete(DeleteBehavior.ClientSetNull)
                .HasConstraintName("FK_Shippings_Orders");
        });

        OnModelCreatingPartial(modelBuilder);
    }

    partial void OnModelCreatingPartial(ModelBuilder modelBuilder);
}

Example entity created in Entities directory

public partial class Order 
{
    public int OrderId { get; set; }
    [other properties...]
    
    [example relationship]
    public virtual ICollection Shippings { get; set; } = new List();
}

The `partial` Class and `OnModelCreatingPartial`

The generated class is marked partial. This is intentional - it lets you extend the context in a separate file without touching the generated code. If you re-scaffold after a schema change, your customizations survive because they live in a different file.

OnModelCreatingPartial is a partial method hook at the end of OnModelCreating. Add your own configuration in a second partial file by implementing this method there. Never add custom config directly to the generated file.

The Two Constructors

The parameterless constructor exists for design-time tooling. The second constructor - (DbContextOptions options) - is the one used at runtime when the context is registered via DI. You do not need to touch either of these.

`virtual` DbSet Properties

All DbSet properties are marked virtual. This enables mocking in unit tests - a test double can override these properties and return in-memory data without hitting a real database.

`OnConfiguring`

This is the first thing to fix. The scaffolder drops the connection string directly into OnConfiguring and adds a compiler warning telling you to remove it. Delete the entire method - it is only needed when no options are provided via the constructor, which never happens in a properly configured DI setup.

`OnModelCreating` - The Real Value

This is where scaffolding earns its keep. Every relationship, constraint, column type, max length, and delete behavior is mapped here using Fluent API. Things to note:

HasName("PK__...") captures the actual constraint name from SQL Server - useful if you need to reference it later
HasColumnType("decimal(18,2)") and HasColumnType("datetime") preserve exact SQL Server types that have no direct CLR equivalent
IsUnicode(false) maps to VARCHAR columns - if you see this, the database is using non-Unicode string columns
OnDelete(DeleteBehavior.ClientSetNull) reflects the FK delete rule defined in the database - this is not EF’s default, it was read directly from the schema
HasConstraintName preserves the original FK constraint name from SQL Server

`partial void OnModelCreatingPartial`

This is the extension point. In a second file, implement it like this to add custom configuration without modifying generated code:

public partial class ECommerceDbContext
{
    partial void OnModelCreatingPartial(ModelBuilder modelBuilder)
    {
        // your custom Fluent API configuration here
        modelBuilder.Entity()
            .HasQueryFilter(p => !p.IsDeleted);
    }
}

Cleaning Up After Scaffolding

Two things to do immediately after the scaffold command runs.

Move the DbContext Up One Level

The DbContext gets placed inside the Entities output folder alongside all the entity files. Move it one level up to the project root or a dedicated Data folder, and update its namespace accordingly.

Remove `OnConfiguring` and Move the Connection String

Delete the entire OnConfiguring method. Move the connection string to appsettings.json:

Then register the context in Program.cs:

builder.Services.AddDbContext(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DbConnectionString")));

Querying with the Scaffolded Context

With the context registered, a single endpoint demonstrates the full navigation chain across all the generated relationships:

csharp

app.MapGet("/api/demo", async (ECommerceDbContext dbContext) =>
{
    var results = await dbContext.Orders
        .Include(o => o.Customer)
        .Include(o => o.OrderDetails)
            .ThenInclude(od => od.Product)
                .ThenInclude(p => p.Category)
        .Include(o => o.Shippings)
        .Select(o => new
        {
            CustomerName = $"{o.Customer.FirstName} {o.Customer.LastName}",
            o.OrderDate,
            o.TotalAmount,
            o.Status,
            Products = o.OrderDetails.Select(od => new
            {
                od.Product.ProductName,
                od.Quantity,
                od.UnitPrice,
                Categories = od.Product.Category.Name
            }).ToList()
        })
        .ToListAsync();

    return results;
});

Include / ThenInclude follows the navigation properties generated by scaffolding - no manual wiring needed
Select projects the result to avoid over-fetching - never return raw EF entities from an API endpoint
ToListAsync keeps the call non-blocking

Pros and Cons of Database First Scaffolding

Pros

Instant model generation from any existing schema - no manual entity writing
All Fluent API configuration is generated automatically, including complex relationships
The partial class pattern lets you extend safely without touching generated code
Reduces human error when dealing with large or complex schemas

Cons

Generated code is verbose and can be hard to read in large schemas
Re-scaffolding on schema changes can overwrite customizations not protected by the partial pattern
The OnConfiguring connection string issue requires a cleanup step every time
Navigation property and constraint names are sometimes awkward and may need renaming

When to Use Database First

Use Database First when the database already exists and is maintained independently - legacy systems, DBAs who own the schema, shared databases across multiple services. If you control the database lifecycle from day one, Code First with migrations is the better fit.

Key Takeaways

Three NuGet packages are required before scaffolding: Tools, Design, and the database provider.
The scaffold command generates both the DbContext and all entities with full Fluent API configuration in a single step.
Always delete the OnConfiguring method from the generated context and move the connection string to appsettings.json.
virtual DbSet properties exist for testability - they allow mocking the context in unit tests.
OnDelete(DeleteBehavior.ClientSetNull), IsUnicode(false), and exact column types like decimal(18,2) are read directly from the database schema - do not change them without understanding the underlying constraint.

Connect with me:

Blog

YouTube

Want to sponsor this newsletter? Let’s work together →

Refit - The Better Way to Consume APIs in .NET

Remigiusz Zalewski — Sat, 04 Apr 2026 06:01:56 GMT

Introduction

You’re integrating with an external API. You create a service, inject HttpClient, build the URL, append query parameters, deserialize the response. It works. You do it again for the next endpoint. And the next. By endpoint number eight, you’re copy-pasting the same structure with minor variations, and every new developer on the team has to understand your bespoke HTTP layer just to add a method.

This is the reality for most .NET teams consuming third-party APIs. The Typed HttpClient pattern with IHttpClientFactory is solid and production-proven - but it generates a lot of repetitive code that scales poorly when an API surface grows.

Refit solves this by generating the HTTP service for you at compile time, based on a C# interface you define. You write the contract, Refit writes the implementation.

In this post I’ll walk through both approaches using a real OpenWeatherMap integration: first the full typed HttpClient setup with a delegating handler, then the same thing rebuilt with Refit. You’ll see exactly where the complexity lives and what disappears.

🎬 Watch the full video here:

Setting Up the Project

The demo project targets .NET 10 and uses following nuget package:

The key package for Refit is Refit.HttpClientFactory - it provides the AddRefitClient() extension that integrates cleanly with IHttpClientFactory.

Approach 1: Typed HttpClient with IHttpClientFactory

Configuration and Options

Any external API integration starts with configuration. The OpenWeatherMap API needs a base URL, an API key, and a units setting. These go into appsettings.json:

{
  "OpenWeatherApi": {
    "BaseUrl": "https://api.openweathermap.org/data/2.5",
    "ApiKey": "",
    "Units": "metric"
  }
}

Rather than injecting IConfiguration directly into services, the Options pattern is the right approach. Create a strongly typed options class:

public class OpenWeatherApiOptions
{
    public const string OpenWeatherApiOptionsKey = "OpenWeatherApi";

    [Required]
    [Url]
    public string BaseUrl { get; set; } = string.Empty;

    [Required]
    public string ApiKey { get; set; } = string.Empty;

    [Required]
    public string Units { get; set; } = string.Empty;
}

Key points:

OpenWeatherApiOptionsKey is a const string used to bind to the correct appsettings.json section
Data annotations ([Required], [Url]) enable startup validation
Using string.Empty as defaults satisfies the nullable reference type compiler

builder.Services.AddOptions()
    .BindConfiguration(OpenWeatherApiOptions.OpenWeatherApiOptionsKey)
    .ValidateDataAnnotations()
    .ValidateOnStart();

ValidateOnStart() is important - without it, validation only triggers on first use. With it, a misconfigured API key will fail immediately at startup rather than silently at runtime.

The Service and Interface

Start with the interface that defines the contract:

public interface IOpenWeatherApiService
{
    Task GetCurrentWeatherDataAsync(
        double lat,
        double lon,
        CancellationToken ct);
}

And the implementation. Notice how HttpClient is injected via primary constructor and the query parameters are built manually in the URL string:

public class OpenWeatherApiService(HttpClient client) : IOpenWeatherApiService
{
    public async Task GetCurrentWeatherDataAsync(
        double lat,
        double lon,
        CancellationToken ct)
    {
        var response = await client.GetFromJsonAsync(
            $"weather?lat={lat}&lon={lon}");
        return response;
    }
}

Key points:

HttpClient is injected by IHttpClientFactory - the base address and any shared configuration are set at registration time, not inside the service
The method builds a relative URL with lat and lon as query parameters
Notice what is missing: the API key and units are not here - that’s the job of the delegating handler covered next
Every new endpoint from this API means a new method in this class and a new entry in the interface

The Delegating Handler

Right now the service only appends lat and lon. But every request to OpenWeatherMap also needs appid (the API key) and units. You could add those to every method call - but that means touching every method whenever the API contract changes, and duplicating the same parameter wiring across dozens of endpoints.

A delegating handler solves this cleanly. It sits in the HTTP pipeline and intercepts every outgoing request before it leaves the application. You override SendAsync, mutate the request, and call base.SendAsync to continue the pipeline.

public class OpenWeatherApiDelegatingHandler(IOptions options)
    : DelegatingHandler
{
    private readonly OpenWeatherApiOptions _options = options.Value;

    protected override async Task SendAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        var uri = request.RequestUri!;
        var separator = uri.Query.Length > 0 ? "&" : "?";
        request.RequestUri = new Uri(
            $"{uri}{separator}appid={_options.ApiKey}&units={_options.Units}");

        return await base.SendAsync(request, cancellationToken);
    }
}

Key points:

Inherits from DelegatingHandler and overrides SendAsync
Detects whether a ? already exists in the query string and appends & or ? accordingly - without this check you’d produce malformed URLs like weather?lat=52&lon=13??appid=...
Reads the API key and units from IOptions - no magic strings anywhere in the pipeline
This is also the right place for Authorization: Bearer {token} headers for token-authenticated APIs - one handler, all requests covered

The delegating handler makes OpenWeatherApiService completely unaware of authentication or shared parameters. Adding 15 more endpoints to the interface means zero changes to the handler.

Registering Everything in Program.cs

builder.Services.AddTransient();

builder.Services.AddHttpClient
    ((provider, client) =>
    {
        var options = provider
            .GetRequiredService>()
            .Value;
        client.BaseAddress = new Uri(options.BaseUrl);
    })
    .AddHttpMessageHandler();

Key points:

The delegating handler must be registered as Transient before it can be used with AddHttpMessageHandler
ConfigureHttpClient resolves IOptions from the DI container to set the base address - this is why the service itself never needs to know the base URL
AddHttpMessageHandler chains the handler into the request pipeline for this specific typed client

✅ Pros

Full control over every request detail
No additional dependencies beyond what ships with .NET
Works well for simple integrations with one or two endpoints

❌ Cons

Every new endpoint requires a new method in the service class and a matching entry in the interface
The service, interface, and registration all need to be maintained in sync
Boilerplate grows linearly with the number of API endpoints

Approach 2: Refit

Refit takes a different approach entirely. Instead of writing a service class, you declare a C# interface that describes the API contract using attributes. Refit generates the implementation at compile time - the OpenWeatherApiService class disappears completely.

The Interface

The interface that previously only defined the method signature now also carries the full HTTP contract:

public interface IOpenWeatherApiService
{
    [Get("/weather")]
    Task GetCurrentWeatherDataAsync(
        [Query] double lat,
        [Query] double lon,
        CancellationToken ct = default);
}

Key points:

[Get("/weather")] maps to the HTTP GET method and the relative path - note the leading slash, which Refit requires
[Query] attributes map method parameters to URL query parameters automatically - no manual string interpolation
The base URL is still configured at registration time, same as before
No implementation class is needed - this interface is the entire definition of the integration

Registration

builder.Services.AddTransient();

builder.Services.AddRefitClient()
    .ConfigureHttpClient((provider, client) =>
    {
        var options = provider
            .GetRequiredService>()
            .Value;
        client.BaseAddress = new Uri(options.BaseUrl);
    })
    .AddHttpMessageHandler();

The only change from the typed HttpClient registration is AddRefitClient() instead of AddHttpClient(). The delegating handler, options resolution, and base address setup remain identical - Refit slots into the same pipeline.

What Refit Generates

When you set a breakpoint and inspect the injected IOpenWeatherApiService at runtime, you’ll see a class like AutoGeneratedIOpenWeatherApiService - produced by Refit’s source generator at compile time. It wraps HttpClient, builds the request URL from your [Get] and [Query] declarations, and handles deserialization. You get the same runtime behavior as the hand-written service with zero implementation code on your side.

Adding a new endpoint from the same API now means one new method in the interface. No new class, no new registration, no new URL string to construct.

When to Use Typed HttpClient

You have one or two endpoints and adding a new NuGet dependency is not justified
You need fine-grained control over request construction that attributes cannot express
The API requires complex, dynamic query building that varies significantly per call

When to Use Refit

You are integrating with an API that has 5 or more endpoints
You want the interface to serve as living documentation of the external API contract
You want to reduce boilerplate and keep new endpoint additions to a single line

Key Takeaways

The Options pattern with ValidateDataAnnotations() and ValidateOnStart() catches misconfiguration at startup, not silently at runtime.
Delegating handlers intercept every outgoing request in the pipeline - use them for API keys, auth headers, or any parameter that repeats across all endpoints.
Without a delegating handler, shared parameters like appid and units leak into every service method, making future changes expensive.
Refit replaces the service implementation class entirely by generating it from a decorated interface at compile time - AddRefitClient() is the only registration change needed.
For small integrations with one or two endpoints, typed HttpClient is perfectly fine. Refit pays off as the API surface grows.
Both approaches work side by side in the same application - mix them based on the complexity of each integration.

Resources

https://github.com/reactiveui/refit

Connect with me:

YouTube

Blog

Want to sponsor this newsletter? Let’s work together →

EF Core Stored Procedures: Complete Guide for .NET Developers

Remigiusz Zalewski — Sat, 28 Mar 2026 07:00:45 GMT

Introduction

LINQ is convenient, but it is not always the right tool. Complex filtering logic, multi-table aggregations, and performance-sensitive queries can become unreadable or impossible to express cleanly in LINQ. Stored procedures solve this - the SQL lives in the database, it is reusable across applications, and it executes faster than the equivalent dynamically generated query.

The question is how to manage stored procedures properly in a Code First EF Core project. You do not want to run raw SQL scripts manually against every environment. You want them version-controlled, applied automatically with migrations, and called safely from your API without opening the door to SQL injection.

This post covers the full workflow: creating stored procedures inside EF Core migrations, calling them from Minimal API endpoints using FromSqlRaw, FromSqlInterpolated, and ExecuteSqlInterpolatedAsync, and understanding when to reach for each method.

🎬 Watch the full video here:

The Starting Point

The demo project is a Minimal API with two entities - Author and Book:

public class Author
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Country { get; set; }
}

public class Book
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Category { get; set; } = string.Empty;
    public Author Author { get; set; }
    public int AuthorId { get; set; }
}

Four endpoints exist initially, all written with LINQ. The goal is to replace them with stored procedure equivalents, with each procedure created and managed entirely through EF Core migrations.

What Are Stored Procedures and When to Use Them

A stored procedure is a named SQL statement stored inside the database itself. It can be called by any application that has access to that database, and the database engine can cache its execution plan for faster repeated execution.

For simple CRUD operations, LINQ is fine and Code First keeps things clean. Stored procedures make sense when:

The SQL is too complex or verbose to express cleanly in LINQ
The query cannot be expressed in LINQ at all
The same logic needs to be shared across multiple applications or services
Raw query performance matters and you want the database engine to optimize the plan

In this demo, the operations are intentionally simple - the point is demonstrating the pattern, not justifying every stored procedure.

Creating Stored Procedures in EF Core Migrations

The right way to manage stored procedures in Code First is through blank migrations. You add an empty migration, write the CREATE PROCEDURE SQL in the Up method, and write the DROP PROCEDURE SQL in the Down method. This keeps every procedure version-controlled and applied automatically with dotnet ef database update.

Creating a Blank Migration

dotnet ef migrations add AddedGetBooks \
  --startup-project StoredProcedures.API \
  --project StoredProcedures.Infrastructure

--startup-project points to where your API lives
--project points to where your DbContext and migrations folder live
The generated migration will have empty Up and Down methods ready for your SQL

Writing the Migration

public partial class AddedGetBooks : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        var createProcedure =
            "CREATE PROCEDURE [dbo].[GetBooks]\n" +
            "AS\n" +
            "BEGIN\n" +
            "    SET NOCOUNT ON;\n" +
            "    SELECT * FROM Books;\n" +
            "END";

        migrationBuilder.Sql(createProcedure);
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {
        var dropStatement = "DROP PROCEDURE [dbo].[GetBooks]";
        migrationBuilder.Sql(dropStatement);
    }
}

Key points:

migrationBuilder.Sql() executes any raw SQL string during migration
SET NOCOUNT ON suppresses row-count messages - always include this in stored procedures
The Down method must drop the procedure so rollbacks work cleanly
Apply with dotnet ef database update --startup-project ... --project ...

A Procedure with Parameters

public partial class AddedGetBooksByCategoryAndAuthorId : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        var sql =
            "CREATE PROCEDURE GetBooksByCategoryAndAuthorId\n" +
            "    @category NVARCHAR(100),\n" +
            "    @authorId INT\n" +
            "AS\n" +
            "BEGIN\n" +
            "    SET NOCOUNT ON;\n" +
            "    SELECT * FROM Books\n" +
            "    WHERE Category = @category AND AuthorId = @authorId;\n" +
            "END";

        migrationBuilder.Sql(sql);
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {
        var sql = "DROP PROCEDURE GetBooksByCategoryAndAuthorId";
        migrationBuilder.Sql(sql);
    }
}

Parameters are declared with @paramName TYPE after the procedure name
The WHERE clause uses those parameters directly
The pattern for Down is identical - just drop the procedure by name

⚡ Calling Stored Procedures from Minimal API Endpoints

There are three EF Core methods for executing stored procedures, and choosing the right one depends on whether you are querying data or executing a command.

`FromSqlRaw` - No Parameters

Use FromSqlRaw when the stored procedure takes no parameters and you need to return entity results:

app.MapGet("/stored-procedure-get-books", async (DemoDbContext dbContext) =>
{
    var books = await dbContext.Books
        .FromSqlRaw("EXEC GetBooks")
        .ToListAsync();

    return books;
});

FromSqlRaw executes a raw SQL string and maps results to the entity type
Only use this when there are no user-supplied parameters - never concatenate user input into a raw SQL string

`FromSqlInterpolated` - Parameterized Queries

Use FromSqlInterpolated when you need to pass parameters and return entity results. EF Core converts the interpolated string into a parameterized query, which prevents SQL injection:

app.MapGet("/stored-procedure-get-books-by-category-and-authorid",
    async (string category, int authorId, DemoDbContext dbContext) =>
    {
        var books = await dbContext.Books
            .FromSqlInterpolated(
                $"EXEC GetBooksByCategoryAndAuthorId @category={category}, @authorId {authorId}")
            .ToListAsync();

        return books;
    });

The $ prefix makes this an interpolated string, but EF Core does not concatenate the values directly
Each interpolated value is converted to a proper SQL parameter under the hood
Results are mapped back to Book entities automatically

`ExecuteSqlInterpolatedAsync` - Commands (No Return Value)

Use ExecuteSqlInterpolatedAsync for INSERT, UPDATE, and DELETE procedures that do not return rows:

app.MapPost("/stored-procedure-books",
    async (CreateBookRequest createBookRequest, DemoDbContext dbContext) =>
    {
        await dbContext.Database.ExecuteSqlInterpolatedAsync(
            $"EXEC CreateBook @name={createBookRequest.Name}, @category={createBookRequest.Category}, @authorId={createBookRequest.AuthorId}");

        return Results.Ok();
    });

app.MapPut("/stored-procedure-books",
    async (UpdateBookRequest updateBookRequest, DemoDbContext dbContext) =>
    {
        await dbContext.Database.ExecuteSqlInterpolatedAsync(
            $"EXEC UpdateBook @bookId={updateBookRequest.BookId}, @name={updateBookRequest.Name}, @category={updateBookRequest.Category}, @authorId={updateBookRequest.AuthorId}");

        return Results.Ok();
    });

Called on dbContext.Database, not on a DbSet
Async by default - always await it
Same SQL injection protection as FromSqlInterpolated - values are parameterized automatically

The Full `BooksStoredProcedureModule`

public static class BooksStoredProcedureModule
{
    public static void AddBooksStoredProcedureEndpoints(this IEndpointRouteBuilder app)
    {
        app.MapPost("/stored-procedure-books",
            async (CreateBookRequest createBookRequest, DemoDbContext dbContext) =>
            {
                await dbContext.Database.ExecuteSqlInterpolatedAsync(
                    $"EXEC CreateBook @name={createBookRequest.Name}, @category={createBookRequest.Category}, @authorId={createBookRequest.AuthorId}");
                return Results.Ok();
            });

        app.MapPut("/stored-procedure-books",
            async (UpdateBookRequest updateBookRequest, DemoDbContext dbContext) =>
            {
                await dbContext.Database.ExecuteSqlInterpolatedAsync(
                    $"EXEC UpdateBook @bookId={updateBookRequest.BookId}, @name={updateBookRequest.Name}, @category={updateBookRequest.Category}, @authorId={updateBookRequest.AuthorId}");
                return Results.Ok();
            });

        app.MapGet("/stored-procedure-get-books", async (DemoDbContext dbContext) =>
        {
            var books = await dbContext.Books
                .FromSqlRaw("EXEC GetBooks")
                .ToListAsync();
            return books;
        });

        app.MapGet("/stored-procedure-get-books-by-category-and-authorid",
            async (string category, int authorId, DemoDbContext dbContext) =>
            {
                var books = await dbContext.Books
                    .FromSqlInterpolated(
                        $"EXEC GetBooksByCategoryAndAuthorId @category={category}, @authorId={authorId}")
                    .ToListAsync();
                return books;
            });
    }
}

Migrations Keep Everything in Sync

One major benefit of managing stored procedures through migrations is that dropping and recreating the database from scratch works perfectly. Running dotnet ef database update replays all migrations in order - tables first, then each stored procedure gets created automatically.

No manual SQL scripts, no environment drift, no missing procedures in staging. The database state is fully reproducible from migration history alone.

Key Takeaways

Create stored procedures inside blank EF Core migrations using migrationBuilder.Sql() - this keeps them version-controlled and applied automatically.
Always write a DOWN method that drops the procedure so rollbacks work cleanly.
Use FromSqlRaw only for no-parameter queries - never concatenate user input into a raw SQL string.
Use FromSqlInterpolated for parameterized queries that return entities - EF Core converts interpolated values to proper SQL parameters automatically.
Use ExecuteSqlInterpolatedAsync on dbContext.Database for INSERT, UPDATE, and DELETE procedures that do not return rows.
Stored procedures are worth reaching for when the SQL is too complex for LINQ, needs to be shared across applications, or when raw execution performance matters.

Connect with me:

Blog

YouTube

Want to sponsor this newsletter? Let’s work together →

EF Core Performance: N+1, Cartesian Explosion and How to Fix Both

Remigiusz Zalewski — Sat, 21 Mar 2026 07:01:39 GMT

Introduction

You send a single HTTP request. Your app fetches 500 orders. Looks fine. But in the background, EF Core just fired 1501 SQL queries against your database - and the response took 7.5 seconds.

This is the N+1 problem, and it’s one of the most common performance killers in EF Core applications. The frustrating part is that the code causing it looks completely reasonable. No obvious red flags, no suspicious loops - just navigational properties being accessed like normal.

In this article you’ll see exactly why it happens, what Cartesian explosion is, and three different approaches to loading related data - each with different trade-offs depending on your situation.

🎬 Watch the full video here:

🐢 The N+1 Problem

Here’s the endpoint that triggered 1501 queries:

group.MapGet("/nplusone", async (AppDbContext db) =>
{
    var orders = await db.Orders.ToListAsync();
    var results = new List();

    foreach (var order in orders)
    {
        results.Add(new OrderResult(
            order.Id,
            order.Customer.Name,
            [.. order.Items.Select(x => x.ProductName)],
            [.. order.Tags.Select(x => x.Name)]));
    }

    return Results.Ok(results);
});

One call to db.Orders.ToListAsync() fetches the orders. Then in the foreach, accessing order.Customer, order.Items, and order.Tags fires a separate SQL query for each navigational property on each order. With 500 orders and 3 navigational properties each:

1 (initial query) + 3 * 500 = 1501 SQL queries

The root cause is UseLazyLoadingProxies() being enabled in the DbContext configuration - combined with the virtual keyword on navigational properties. EF Core intercepts every property access and goes back to the database silently.

// What enables lazy loading - remove this
builder.Services.AddDbContext(options =>
    options
        .UseSqlServer(builder.Configuration.GetConnectionString("Default"))
        .UseLazyLoadingProxies() // the culprit
        .LogTo(Console.WriteLine, LogLevel.Information)
        .EnableSensitiveDataLogging());

Microsoft disables lazy loading by default for exactly this reason. Remove UseLazyLoadingProxies() and drop the virtual keywords from all navigational properties. After that, accessing them without explicitly loading the data throws a NullReferenceException - which is the right behavior. It forces you to be intentional.

The correct DbContext setup:

builder.Services.AddDbContext(options =>
    options
        .UseSqlServer(builder.Configuration.GetConnectionString("Default"))
        .LogTo(Console.WriteLine, LogLevel.Information)
        .EnableSensitiveDataLogging());

Key points:

Lazy loading is disabled by default in EF Core - do not re-enable it without understanding the query cost
The virtual keyword on navigational properties is what allows lazy loading proxies to intercept access
A NullReferenceException after removing lazy loading is expected - it means you now control what gets loaded

Fix 1: Projections

Projections let you select only the data you actually need. EF Core translates the Select into SQL joins and aggregate functions server-side.

group.MapGet("/projection", async (AppDbContext db) =>
{
    var results = await db.Orders
        .Select(o => new
        {
            o.Id,
            CustomerName = o.Customer.Name,
            o.Total,
            ItemCount = o.Items.Count
        })
        .ToListAsync();

    return Results.Ok(results);
});

This produces a single SQL query with a JOIN and a COUNT aggregate. EF Core also skips change tracking automatically when projecting to anonymous types - no need to call AsNoTracking().

Result: ~230ms for 500 orders.

When Projections Break Down

The moment you include collections in the projection, things change:

group.MapGet("/projection-2", async (AppDbContext db) =>
{
    var results = await db.Orders
        .Select(o => new
        {
            o.Id,
            CustomerName = o.Customer.Name,
            Items = o.Items.Select(x => x.ProductName),
            Tags = o.Tags.Select(x => x.Name)
        })
        .ToListAsync();

    return Results.Ok(results);
});

Including both Items and Tags as collections forces EF Core to perform joins that multiply rows. Every order row gets duplicated for every item, and again for every tag. This is Cartesian explosion - and it caused a 15 second response time in testing.

✅ Use projections when:

Accessing a single navigational property
Using aggregate functions (COUNT, SUM, AVG)
Projecting scalar values only

❌ Avoid projections when:

Including multiple collections in the projected shape

Fix 2: Eager Loading

Eager loading uses Include() to tell EF Core what to load upfront. You get the full object graph and map it yourself:

group.MapGet("/eager", async (AppDbContext db) =>
{
    var orders = await db.Orders
        .Include(o => o.Customer)
        .Include(o => o.Items)
        .Include(o => o.Tags)
        .AsNoTracking()
        .ToListAsync();

    var results = orders.Select(o => new OrderResult(
        o.Id,
        o.Customer.Name,
        [.. o.Items.Select(x => x.ProductName)],
        [.. o.Tags.Select(x => x.Name)])).ToList();

    return Results.Ok(results);
});

AsNoTracking() is essential for read-only endpoints - without it, EF Core tracks every returned entity, adding memory and CPU overhead that serves no purpose here.

The problem is the same as with projection-2. Multiple Include() calls on collections produce SQL JOINs that multiply result rows. With three collections the database returns every combination of order, item, and tag as a separate row. In testing this endpoint timed out completely - the Cartesian explosion was severe enough that the API could not return a response at all.

✅ Use eager loading when:

Including a single collection
You need the full entity, not just specific columns

❌ Avoid eager loading when:

Including multiple collections simultaneously - Cartesian explosion will occur

⚡ Fix 3: AsSplitQuery

AsSplitQuery() solves Cartesian explosion when you need multiple collection includes. Instead of one JOIN-heavy query that multiplies rows, EF Core fires separate SQL queries per collection and assembles the result in memory.

group.MapGet("/split", async (AppDbContext db) =>
{
    var orders = await db.Orders
        .Include(o => o.Customer)
        .Include(o => o.Items)
        .Include(o => o.Tags)
        .AsNoTracking()
        .AsSplitQuery()
        .ToListAsync();

    var results = orders.Select(o => new OrderResult(
        o.Id,
        o.Customer.Name,
        [.. o.Items.Select(x => x.ProductName)],
        [.. o.Tags.Select(x => x.Name)])).ToList();

    return Results.Ok(results);
});

One method call added to the eager loading endpoint. That’s it.

Result: ~1 second on the first request, ~700ms on the second. No timeout. No Cartesian explosion.

Trade-offs to Know

AsSplitQuery is not free:

High database latency multiplies the cost - each split query is a separate round-trip, so latency stacks up
No consistency guarantee - if data changes between the split queries executing, different parts of your result could reflect different database states

✅ Use AsSplitQuery when:

Including multiple collections that would otherwise cause Cartesian explosion
Database latency is low
You can tolerate slight inconsistency between collections

❌ Avoid AsSplitQuery when:

Database latency is high and you have strict performance budgets
You need guaranteed snapshot consistency across all included collections

Key Takeaways

Lazy loading is disabled by default in EF Core for good reason - never re-enable it in production without understanding the 1+N query cost.
Use projections for scalar properties and aggregate functions, but avoid projecting into multiple collections or you will hit Cartesian explosion just as fast as with eager loading.
Multiple Include() calls on collections produce Cartesian explosion - the result set grows exponentially and can cause full request timeouts.
AsSplitQuery() eliminates Cartesian explosion by splitting includes into separate queries - one method call away from fixing a timeout.
Always add AsNoTracking() for read-only queries - it removes change tracking overhead that serves no purpose when you are not updating data.

Connect with me

Follow me on LinkedIn

Follow me

Subscribe on YouTube

Subscribe on Youtube

Want to sponsor this newsletter? Let’s work together →

How to Set Up a Release Pipeline for ASP.NET Core in Azure DevOps

Remigiusz Zalewski — Sat, 14 Mar 2026 07:01:09 GMT

Introduction

At some point, manually deploying your ASP.NET Core app to a server gets old fast. You merge to main, then you open Azure DevOps, kick off a release, RDP into the VM, check the logs - it’s a lot of overhead that compounds with every deploy.

The fix is a proper CD pipeline. Once it’s wired up, every successful CI build triggers a deployment automatically. Your code goes from a merge to a live site without you lifting a finger.

In this article, you’ll see the full setup: provisioning an Azure VM, enabling IIS, installing the .NET Hosting Bundle, connecting the VM to Azure DevOps via a Deployment Group, and building the Release Pipeline itself with an IIS Web App Deploy task.

🎬 Watch the full video here:

⚙️ Provisioning the Azure Virtual Machine

If you already have a VM running Windows Server with IIS, skip this section and jump straight to the Deployment Group setup.

For everyone starting fresh: in the Azure Portal, create a new Virtual Machine with these settings:

OS: Windows Server 2025 Datacenter Gen 2
Inbound ports: HTTP and HTTPS only
RDP: do not open to all IPs - lock it down after creation

On RDP specifically - once the VM is created, go to the Network Security Group and add an inbound rule that allows RDP only from your own public IP. If you leave RDP open to the world and your credentials ever leak, the machine is exposed. Check your current IP at whatismyip.com, then create the rule with that IP as the source.

🌐 Enabling IIS and Installing the .NET Hosting Bundle

Connect to the VM via RDP and do two things before touching Azure DevOps.

Enable IIS

Open Server Manager, go to Manage > Add Roles and Features, and enable the Web Server (IIS) role. Once installed, open IIS Manager from the Tools menu - you should see a Default Web Site already present.

Install the .NET Hosting Bundle

Your ASP.NET Core app needs the Hosting Bundle installed on the server - not just the runtime. Open a command prompt and run:

dotnet --list-runtimes

If you get “command not found” or an empty list, the bundle is not installed. Download the correct version from the official .NET download page (in this case .NET 10) and select the Hosting Bundle option - not the SDK or the runtime alone.

After installation, restart the VM and verify:

dotnet --list-runtimes

You should now see the installed runtime. In IIS Manager, go to the server node > Modules, and confirm that AspNetCoreModuleV2 is listed. That module is what allows IIS to host ASP.NET Core apps as a reverse proxy.

Key points:

Always install the Hosting Bundle, not just the runtime
The ASP.NET Core Module V2 must appear in IIS Modules before any deployment
Match the bundle version to the target framework of your application

🔗 Connecting the VM to Azure DevOps via a Deployment Group

A Deployment Group is how Azure DevOps establishes a trusted connection to your server. Once registered, the VM appears as a deployment target inside your release pipeline.

In Azure DevOps, go to Pipelines > Deployment Groups and click Add a deployment group. Give it a name - for example ProductionDeploymentGroup.

Azure DevOps will generate a PowerShell registration script. Check the option to use a Personal Access Token for authentication, then copy the script.

On the VM, open PowerShell as Administrator, paste the script, and press Enter through the default prompts. When the script completes, go back to the Deployment Groups page in Azure DevOps and refresh - you should see your VM listed with a status of Online and Healthy.

Key points:

Run the registration script with admin privileges
The agent installed by the script runs as a Windows service on the VM
One Deployment Group can hold multiple VMs for multi-server deployments

🚀 Building the Release Pipeline

Now for the CD pipeline itself.

Go to Pipelines > Releases > New Pipeline. You will configure two things: the artifact source and the deployment stage.

Artifact Source

Click Add an artifact and select your CI build pipeline as the source. Enable the Continuous Deployment trigger (the lightning bolt icon). This is what makes every successful CI build automatically kick off a new release - no manual intervention needed.

Deployment Stage

Add a stage and select the IIS Website Deployment template. Rename the stage to something like Deploy to IIS Server for clarity.

Click into the stage tasks. You will configure three tasks:

Deployment process

Setup the binding that you would like to associate your ASP.NET Core application with. In my case it will be port 81 with http. Choose your desired website name.

IIS Deployment

Set the Deployment Group to ProductionDeploymentGroup
Enable Allow scripts to access the OAuth token

IIS Web App Manage

Configure the website and app pool that Azure DevOps will create or update on the VM:

Website name: TaskManager (or your app name) - will be automatically fetched from previous step
Physical path: a dedicated folder on the VM, e.g. %SystemDrive%\inetpub\wwwroot\TaskManager
Physical path authentication: Application User
Binding port: automatically fetched from the first step
App pool name: TaskManager
.NET CLR version: No Managed Code (required for ASP.NET Core)
Identity: Custom Account - use pipeline variables for credentials (see below)

IIS Web App Deploy

Leave the Package or Folder field pointing to the artifact zip from your CI pipeline. Azure DevOps populates this automatically when you selected the artifact source.

Pipeline Variables

Instead of hardcoding VM credentials, use pipeline variables. Go to the Variables tab and add:

username - your VM admin username
password - your VM admin password (mark as secret)

Reference them in the app pool identity fields as $(username) and $(password).

Running Your First Release

Save the pipeline as CD-[YourAppName] and click Create a Release. Watch the logs - each task should complete with a green tick.

Once the pipeline finishes, open IIS Manager on the VM. Your site should appear alongside the Default Web Site. Click Browse and confirm the application loads. If you have a Swagger endpoint or scalar, navigate to /swagger or/scalar to verify the API is responding correctly.

From this point forward, every push that triggers your CI build will also trigger this release pipeline and deploy the latest version automatically.

Key Takeaways

Register your VM with Azure DevOps via a Deployment Group before building any release pipeline - it is the foundation of the connection.
Always install the .NET Hosting Bundle on the IIS server, not just the runtime, and verify that AspNetCoreModuleV2 is present in IIS Modules.
Lock RDP access to your specific IP in the Network Security Group - never leave it open to all addresses.
Use pipeline variables for VM credentials instead of hardcoding them in the pipeline configuration.
Enable the Continuous Deployment trigger on your artifact source to achieve true CD - zero manual steps from code push to live deployment.

Connect with me:

Follow me on LinkedIn
Linkedin
Subscribe on YouTube
YouTube
Want to sponsor this newsletter? Let’s work together →

Setup CI Build Pipeline in Azure DevOps for ASP.NET Core Web API

Remigiusz Zalewski — Sat, 07 Mar 2026 07:01:24 GMT

Introduction

Let’s say you have a .NET application on your local PC and you’d like to start using Azure DevOps - to store your code, automate builds, and run unit tests on every change.

Where do you even start?

In this article we’ll go from point zero - Visual Studio and your .NET code on your machine - to a fully working CI (Continuous Integration) pipeline in Azure DevOps that:

Pushes your existing code to Azure Repos
Builds your application on every merge to main
Runs your unit tests automatically
Produces a deployable build artifact (a ZIP of your published app)
Validates every pull request before it can be merged - separated PR verification pipeline

🎬 Watch the full video here:

Setting Up Azure DevOps

If you’re starting from scratch, follow these steps:

Create a Microsoft account if you don’t have one
Go to Azure DevOps and select “Get started for free”
Create an organization
Create a new project inside that organization

Once inside your project you’ll see the main sections: Boards, Repos, Pipelines, Test Plans, and Artifacts. We’ll be working mostly with Repos and Pipelines.

Pushing Your Code to Azure Repos

Navigate to Repos → Files. Azure DevOps gives you a few options to get your code in:

Push an existing local repository - use the git commands shown on the page to add Azure Repos as a remote and push your full commit history
Import from GitHub - paste your GitHub repo URL and provide credentials if needed
Initialize a new empty repository - useful if you’re starting fresh; clone it locally, copy your code in, then commit and push

In the tutorial I created a new repository called TaskManager and used the “push an existing repository” command since the project was already using Git locally:

git remote add origin 
git push -u origin --all

After refreshing the page, all code and full commit history appeared in Azure Repos.

If you’re not using Git yet, the recommended path is: create the repo with the Visual Studio .gitignore template → clone it locally → copy your code in → git add, commit, and push.

The Two YAML Pipeline Files

All pipeline logic lives in YAML files that you version alongside your code. We’ll create two:

Build.yaml - triggers on merges to main, builds the app, runs tests, publishes the app, and uploads the artifact
PullRequestVerification.yaml - triggers on pull requests targeting main, builds the app and runs tests as a quality gate

Create both files by right-clicking the solution in Visual Studio → Add → New Item.

Build.yaml - CI Build Pipeline

This pipeline runs every time a commit lands on main (e.g. after a PR is merged). It builds the app, runs tests, publishes, and uploads the artifact.

trigger:
  branches:
    include:
      - main
  paths:
    exclude:
      - "*.md"

variables:
  buildConfiguration: "Release"
  dotnetVersion: "10.0.x"
  solutionPath: "TaskManager.slnx"
  unitTestsPath: "TaskManager.Application.Tests/TaskManager.Application.Tests.csproj"

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: UseDotNet@2
    displayName: "Install .NET $(dotnetVersion)"
    inputs:
      packageType: "sdk"
      version: $(dotnetVersion)

  - task: DotNetCoreCLI@2
    displayName: "Restore"
    inputs:
      command: "restore"
      projects: $(solutionPath)

  - task: DotNetCoreCLI@2
    displayName: "Build"
    inputs:
      command: "build"
      projects: $(solutionPath)
      arguments: "--configuration $(buildConfiguration) --no-restore"

  - task: DotNetCoreCLI@2
    displayName: "Run unit tests"
    inputs:
      command: "test"
      projects: $(unitTestsPath)
      arguments: "--configuration $(buildConfiguration) --no-build"
      publishTestResults: true

  - task: DotNetCoreCLI@2
    displayName: "dotnet publish"
    inputs:
      command: "publish"
      projects: "TaskManager.API/TaskManager.API.csproj"
      arguments: "--configuration $(buildConfiguration) --no-build --output $(Build.ArtifactStagingDirectory)/drop"

  - task: PublishBuildArtifacts@1
    displayName: "Upload artifact"
    inputs:
      PathtoPublish: "$(Build.ArtifactStagingDirectory)/drop"
      ArtifactName: "drop"
      publishLocation: "Container"

A few things worth noting:

Markdown files are excluded from the trigger - changes to docs don’t cause a rebuild
--no-restore and --no-build flags avoid repeating work already done in earlier steps
Build.ArtifactStagingDirectory is a temporary holding area on the agent; the PublishBuildArtifacts task is what actually ships those files to Azure DevOps storage so they’re accessible from the pipeline UI and can be picked up by a release pipeline for deployment

PullRequestVerification.yaml - PR Quality Gate

This pipeline is the gatekeeper for the main branch. It runs on every pull request targeting main - not on direct commits.

trigger: none

pr:
  branches:
    include:
      - main
  paths:
    exclude:
      - "*.md"

variables:
  buildConfiguration: "Release"
  dotnetVersion: "10.0.x"
  solutionPath: "TaskManager.slnx"
  unitTestsPath: "TaskManager.Application.Tests/TaskManager.Application.Tests.csproj"

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: UseDotNet@2
    displayName: "Install .NET $(dotnetVersion)"
    inputs:
      packageType: "sdk"
      version: $(dotnetVersion)

  - task: DotNetCoreCLI@2
    displayName: "Restore"
    inputs:
      command: "restore"
      projects: $(solutionPath)

  - task: DotNetCoreCLI@2
    displayName: "Build"
    inputs:
      command: "build"
      projects: $(solutionPath)
      arguments: "--configuration $(buildConfiguration) --no-restore"

  - task: DotNetCoreCLI@2
    displayName: "Run unit tests"
    inputs:
      command: "test"
      projects: $(unitTestsPath)
      arguments: "--configuration $(buildConfiguration) --no-build"
      publishTestResults: true

trigger: none explicitly disables push-based triggers. The pr block is what activates this pipeline - whenever someone opens or updates a pull request targeting main, this kicks off automatically.

Creating the Pipelines in Azure DevOps

Push both YAML files to main, then:

Go to Pipelines → Pipelines → New Pipeline
Select Azure Repos Git → choose your repository
Select Existing Azure Pipelines YAML file
Pick /build.yaml → Save
Repeat for /pull-request-verification.yaml

Rename them for clarity via the three-dot menu:

CI-Build–Task Manager
PullRequestVerification–TaskManager

Enabling Branch Policy on Main

To enforce the PR pipeline as a required check before merging:

Go to Repos → Branches
Click the three dots next to main → Branch policies
Under Build validation → Add build policy
Select the PullRequestVerification–TaskManager pipeline
Set trigger to Automatic, policy to Required
Save

Now no pull request can be merged to main unless the build and tests pass.

End-to-End Test

To verify everything works:

Create a feature branch
Make a small change and push
Open a pull request targeting main

You’ll see the PR verification pipeline queue automatically. Once it passes (build succeeded, all unit tests green), you can complete the merge.

After merging, the CI Build pipeline kicks off on main - builds, tests, publishes, and uploads the artifact. The result is a TaskManager.API.zip in the Artifacts tab, ready for deployment.

Key Takeaways

Azure Repos stores your code and full Git history - push your existing repo with a single command
Build.yaml - CI pipeline triggered on main; builds, tests, publishes, and uploads a deployable artifact
PullRequestVerification.yaml - PR gate; builds and runs tests before any merge is allowed
trigger: none + pr block - the correct way to restrict a pipeline to PR events only
--no-restore / --no-build flags - skip redundant work between pipeline steps
PublishBuildArtifacts - transfers files from the build agent to Azure DevOps storage; without this step, the artifact doesn’t exist outside the agent
Branch policies - enforce the PR pipeline as a required check on main so broken code can never be merged

What’s Next?

The next tutorial will cover creating a release pipeline that picks up this artifact and deploys it to an environment. Make sure to subscribe so you don’t miss it.

Resources

Azure DevOps Documentation: https://learn.microsoft.com/en-us/azure/devops/
Azure Pipelines YAML reference: https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/

Connect with me:

Follow me on LinkedIn

Follow me

Subscribe on YouTube

Subscribe on Youtube

Want to sponsor this newsletter? Let’s work together →

Insane Performance Boost in EF Core using Entity Framework Extensions

Remigiusz Zalewski — Sat, 28 Feb 2026 07:01:32 GMT

Introduction

Imagine that you’ve built a great application using .NET and Entity Framework Core. You start to process thousands - or tens of thousands - of records at once, and you notice a huge bottleneck: your application is getting slower and slower.

Standard EF Core is like a delivery driver who takes one package at a time to the same house, driving back and forth a thousand times. Entity Framework Extensions is the freight truck that delivers all 1,000 packages in a single trip.

In this article I’ll show you how to use the Entity Framework Extensions library by ZZZ Projects to significantly improve the performance of your .NET application. We’ll compare standard EF Core and EF Extensions on real use-case scenarios with actual benchmark numbers.

In this article, I’ll walk you through:

Installing the EF Extensions NuGet package
Why EF Core slows down at scale
BulkInsert, BulkInsertOptimized
BulkUpdate, BulkDelete
BulkMerge (upsert)
BulkSynchronize (upsert + delete missing)
BulkSaveChanges

🎬 Watch the full video here:

Why Standard EF Core Struggles at Scale

EF Core’s SaveChanges() is convenient - it tracks entity state and handles inserts, updates, and deletes automatically. But it generates one SQL statement per entity. Insert 10,000 products? That’s 10,000 round trips.

There are two reasons this kills performance:

1. The change tracker becomes a bottleneck. Tracking the state of 50,000 objects in memory consumes massive amounts of CPU and RAM. Entity Framework Extensions allows you to process data without the overhead of tracking every single property change - freeing your server to handle actual logic instead of managing memory.

2. Too many database round trips. You can see it directly in the console: EF Core floods it with individual INSERT statements, one per record. EF Extensions reduces all of those into a single bulk operation.

Installing Entity Framework Extensions

NuGet package:

dotnet add package Z.EntityFramework.Extensions.EFCore

Or search for Z.EntityFramework.Extensions.EFCore directly in the Visual Studio NuGet package manager.

The package supports .NET 10 and works with:

SQL Server
PostgreSQL
MySQL
Oracle
SQLite

Website and documentation:

https://entityframework-extensions.net - full docs, online benchmarks, and live examples.

Licensing: A free trial is available so you can evaluate the library end-to-end. For commercial projects, a paid license is required from ZZZ Projects. Check the pricing page once you’ve benchmarked it against your own workloads.

Benchmarks at a Glance

All results below are measured on 10,000 records against a PostgreSQL database.

Insert: ~2,800 ms → 177 ms (~16×)
Insert Optimized: ~2,800 ms → 72 ms (~39×)
Update: ~1,500 ms → 100 ms (~15×)
Delete: ~800 ms → 31 ms (~26×)
Merge (upsert): ~1,800 ms → ~100 ms (~18×)
Synchronize: ~1,700 ms → 126 ms (~13×)
BulkSaveChanges: ~1,400 ms → 425 ms (~3×)

Bulk Insert

EF Core (standard):

await context.Products.AddRangeAsync(products);
await context.SaveChangesAsync();

EF Extensions:

await context.BulkInsertAsync(products);

Result: ~2,800 ms → 177 ms.

Need even more speed and don’t need output values (like generated IDs) back? Use the optimized variant:

await context.BulkInsertOptimizedAsync(products);

This skips the output value pass-back entirely, dropping the operation to 72 ms -roughly 39× faster than standard EF Core.

Bulk Update

EF Core:

foreach (var p in products)
    p.Price *= 1.10m;
await context.SaveChangesAsync();

EF Extensions:

foreach (var p in products)
    p.Price *= 1.10m;
await context.BulkUpdateAsync(products);

Result: ~1,500 ms → 100 ms - 15× faster.

Bulk Delete

EF Core:

context.Products.RemoveRange(products);
await context.SaveChangesAsync();

EF Extensions:

await context.BulkDeleteAsync(products);

Result: ~800 ms → 31 ms - over 25× faster.

Bulk Merge (Upsert)

A merge inserts new records and updates existing ones in a single operation. EF Extensions automatically detects what needs to be inserted vs. updated.

EF Core (manual):

foreach (var p in existing)
    p.Price *= 1.15m;
context.Products.AddRange(incoming);
await context.SaveChangesAsync();

EF Extensions:

foreach (var p in existing)
    p.Price *= 1.15m;
var all = existing.Concat(incoming).ToList();
await context.BulkMergeAsync(all);

Result (5,000 updates + 5,000 inserts = 15,000 total): ~1,800 ms → ~100 ms.

Bulk Synchronize

Synchronize goes one step further than Merge - it also deletes records that are not in your source list:

Rows that match the entity key are updated
Rows in the source but not in the database are inserted
Rows in the database but not in the source are deleted

Think of it as mirroring your source to the database.

EF Core (manual - a lot of code to get right):

var existingIds = source.Where(p => p.Id > 0).Select(p => p.Id).ToHashSet();
var toDelete = await context.Products
    .Where(p => !existingIds.Contains(p.Id)).ToListAsync();
context.Products.RemoveRange(toDelete);
foreach (var p in source.Where(p => p.Id > 0))
    context.Products.Update(p);
context.Products.AddRange(source.Where(p => p.Id == 0));
await context.SaveChangesAsync();

EF Extensions:

await context.BulkSynchronizeAsync(source);

Result: ~1,700 ms → 126 ms - and a fraction of the code.

Bulk SaveChanges

Already using the EF Core change tracker with a mix of Add, Update, and Delete? Drop in BulkSaveChangesAsync() as a near-zero-friction replacement:

await context.BulkSaveChangesAsync(); // instead of SaveChangesAsync()

This is the easiest migration path if you have existing code and just want a performance lift.

Result on a mixed Add/Update/Delete workload: ~1,400 ms → 425 ms.

When Should You Reach for This?

You don’t need bulk operations for typical CRUD in a web app handling a handful of records at a time. But if any of these apply, the standard EF Core approach will hurt:

Importing data from CSVs or external feeds
Syncing records between systems
Running nightly price or inventory updates across thousands of rows
Handling data migrations

A one-line swap to BulkInsertAsync, BulkMergeAsync, or BulkSynchronizeAsync makes a real difference.

Key Takeaways

BulkInsertAsync - replaces AddRangeAsync + SaveChangesAsync, up to 16× faster
BulkInsertOptimizedAsync - skips output values for maximum insert speed (~40×)
BulkUpdateAsync - replaces foreach + SaveChangesAsync, 15× faster
BulkDeleteAsync - replaces RemoveRange + SaveChangesAsync, 25× faster
BulkMergeAsync - upsert in one call, auto-detects insert vs. update
BulkSynchronizeAsync - upsert + deletes records missing from source
BulkSaveChangesAsync - drop-in replacement for SaveChangesAsync with change tracker
Free trial available - commercial license required for production use

Resources

Entity Framework Extensions:

https://entityframework-extensions.net

EF Core Documentation: https://learn.microsoft.com/en-us/ef/core/

Connect with me:

Follow me on LinkedIn
Follow me
Subscribe on YouTube
Subscribe on Youtube
Want to sponsor this newsletter? Let’s work together →

Authentication using ASP.NET Core Identity (.NET 10)

Remigiusz Zalewski — Sat, 21 Feb 2026 07:01:48 GMT

Introduction

If you’ve ever built a .NET Web API that needed authentication, you know the drill: create an AuthController, wire up UserManager, write register/login endpoints from scratch...

It’s a lot of boilerplate.

Not anymore.

Starting with .NET 8 and improved in .NET 10, ASP.NET Core ships with Identity API Endpoints - a set of ready-made endpoints for registration, login, token refresh, and more, all backed by ASP.NET Core Identity and Bearer tokens.

In this article, I’ll walk you through setting up authentication from zero in a .NET 10 Minimal API project:

Installing and configuring Identity + EF Core
Running database migrations
Using the built-in Identity endpoints
Protecting routes with RequireAuthorization()
Authenticating with Bearer tokens

🎬 Watch the full video here:

What are Identity API Endpoints?

MapIdentityApi() is a single method call that maps all the authentication endpoints you need:

/register - POST - Register a new user
/login - POST - Login and receive a Bearer token
/refresh - POST - Refresh an expired token
/confirmEmail - GET - Confirm email address
/manage/info - GET / POST - Get or update user info

No controllers. Just one line.

Project Setup

1. Create the Project

dotnet new webapi -n IdentityApiDemo --use-minimal-apis
cd IdentityApiDemo

Make sure you’re targeting .NET 10 in your .csproj:


  
    net10.0
    enable
    enable

2. Install Required Packages

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

Or if you prefer SQLite for local development:

dotnet add package Microsoft.EntityFrameworkCore.Sqlite

The Data Model

AppDbContext — Wiring Up Identity

csharp

public class AppDbContext : IdentityDbContext
{
    public AppDbContext(DbContextOptions options) 
        : base(options) { }
}

Key point: Inherit from IdentityDbContext instead of plain DbContext. This automatically includes all the Identity tables (AspNetUsers, AspNetRoles, AspNetUserTokens, etc.) — no extra configuration needed.

Program.cs Setup

Here’s the full Program.cs:

using IdentityApiDemo.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// 1. Add OpenAPI
builder.Services.AddOpenApi();

// 2. Configure DbContext
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");

builder.Services.AddDbContext(options =>
    options.UseSqlServer(connectionString));

// 3. Configure Identity with Bearer token authentication
builder.Services
    .AddIdentityApiEndpoints()
    .AddEntityFrameworkStores();

// 4. Add Authorization
builder.Services.AddAuthorization();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
    app.MapScalarApiReference();
}

app.UseHttpsRedirection();

// 5. Map the built-in Identity endpoints
app.MapIdentityApi();

// 6. Your protected endpoints
app.MapGet("/me", (ClaimsPrincipal user) =>
{
    return Results.Ok(new 
    { 
        Email = user.FindFirstValue(ClaimTypes.Email),
        Id = user.FindFirstValue(ClaimTypes.NameIdentifier)
    });
})
.RequireAuthorization();

app.MapGet("/public", () => Results.Ok("Anyone can see this!"));

await app.RunAsync();

What’s happening here?

AddIdentityApiEndpoints() — registers Identity services and configures Bearer token authentication in one call. No need to manually call AddAuthentication().AddBearerToken().
AddEntityFrameworkStores() — tells Identity to use your EF Core context for persistence.
MapIdentityApi() — maps all the /register, /login, /refresh, etc. routes.
RequireAuthorization() — protects an endpoint; returns 401 Unauthorized if no valid token is provided.

Database Migration

1. Add the Initial Migration

dotnet ef migrations add InitialIdentitySchema

This generates a migration that creates all the Identity tables:

AspNetUsers — your user accounts
AspNetRoles — role definitions
AspNetUserRoles — user-role assignments
AspNetUserClaims — user claims
AspNetUserTokens — tokens (refresh tokens live here)
AspNetUserLogins — external login providers

2. Apply the Migration

dotnet ef database update

Or apply it programmatically on startup:

// In Program.cs, before app.Run()
using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService();
    await db.Database.MigrateAsync();
}

Important: The automatic migration approach is convenient in development but should be handled carefully in production. Consider using a deployment pipeline to run migrations separately.

Using the Identity Endpoints

Register a New User

POST /register
Content-Type: application/json

{
  "email": "john@example.com",
  "password": "SecurePass123!"
}

Response: 200 OK (empty body on success)

Login and Get a Bearer Token

POST /login
Content-Type: application/json

{
  "email": "john@example.com",
  "password": "SecurePass123!"
}

Response:

{
  "tokenType": "Bearer",
  "accessToken": "eyJhbGciOiJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNobWFjLXNoYTI1NiIsInR5cCI6IkpXVCJ9...",
  "expiresIn": 3600,
  "refreshToken": "CfDJ8NzFy..."
}

The accessToken is a standard Bearer token. Use it in subsequent requests.

Call a Protected Endpoint

GET /me
Authorization: Bearer eyJhbGciOiJodHRwOi8vd3d3...

Response:

{
  "email": "john@example.com",
  "id": "a3f4b2c1-..."
}

Without the token (or with an expired one):

401 Unauthorized

Refresh an Expired Token

POST /refresh
Content-Type: application/json

{
  "refreshToken": "CfDJ8NzFy..."
}

Response:

{
  "tokenType": "Bearer",
  "accessToken": "eyJhbGciOi...",
  "expiresIn": 3600,
  "refreshToken": "CfDJ8Abc..."
}

The old refresh token is invalidated and a new one is issued.

Protecting Endpoints with RequireAuthorization()

Basic Protection

// Must be authenticated (any valid token)
app.MapGet("/dashboard", () => "Your dashboard")
   .RequireAuthorization();

Group-Level Authorization

Apply authorization to a whole group of routes at once instead of repeating .RequireAuthorization() on every endpoint:

var api = app.MapGroup("/api")
             .RequireAuthorization();

api.MapGet("/orders", () => "All orders");
api.MapGet("/products", () => "All products");
api.MapPost("/orders", () => "Create order");
// All three require authentication

Allow Anonymous on Specific Endpoints

If you protect a group but need to open up certain routes:

api.MapGet("/health", () => "OK")
   .AllowAnonymous();

Best Practices

1. Always Use HTTPS in Production

Bearer tokens are credentials - never send them over plain HTTP:

app.UseHttpsRedirection();

2. Don’t Expose Sensitive Claims

// ✅ Only return what the client needs
app.MapGet("/me", (ClaimsPrincipal user) =>
{
    return Results.Ok(new 
    { 
        Email = user.FindFirstValue(ClaimTypes.Email)
    });
})
.RequireAuthorization();

Full Flow Recap

1. POST /register         → Create account
2. POST /login            → Get accessToken + refreshToken
3. GET  /me               → Pass Bearer token in Authorization header
4. POST /refresh          → Get a new accessToken when expired

Key Takeaways

AddIdentityApiEndpoints() — wires up Identity + Bearer auth in one call
MapIdentityApi() — maps /register, /login, /refresh, and more automatically
IdentityDbContext — inherit from it to get all Identity tables for free
Migrations — run dotnet ef migrations add + dotnet ef database update
RequireAuthorization() — protects individual endpoints or entire route groups
Bearer tokens — pass as Authorization: Bearer header; refresh with /refresh

You went from zero to authenticated API in minutes

Resources

Connect with me:

Follow me on LinkedIn

Subscribe on YouTube

Entity Framework Core Loading Strategies - Lazy, Eager, and Explicit Loading Explained

Remigiusz Zalewski — Sat, 14 Feb 2026 07:00:30 GMT

Introduction

If you’ve ever worked with Entity Framework Core, you’ve probably encountered the infamous N+1 query problem or wondered why your API returns incomplete data.

The culprit? Loading strategies.

Entity Framework Core provides three ways to load related data from your database:

1. Lazy Loading - Load data automatically when accessed

2. Eager Loading - Load everything upfront with a single query

3. Explicit Loading - Manually control what gets loaded and when

Each approach has its trade-offs, and choosing the wrong one can lead to performance issues, unnecessary database round-trips, or incomplete data.

In this article, I’ll walk you through all three strategies using a mocked version of “E-Commerce API” built with .NET 10 and Minimal APIs.

🎬 Watch the full video here:

The data model

Before diving into the loading strategies, let’s understand our data structure. We’re building a simplified e-commerce system with the following entities:

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public virtual ICollection Orders { get; set; } = new List();
}

public class Order
{
    public int Id { get; set; }
    public DateTime CreatedAt { get; set; }
    public int CustomerId { get; set; }
    public virtual Customer Customer { get; set; } = null!;
    public virtual ICollection Items { get; set; } = new List();
}

public class OrderItem
{
    public int Id { get; set; }
    public int Quantity { get; set; }
    public int OrderId { get; set; }
    public virtual Order Order { get; set; } = null!;
    public int ProductId { get; set; }
    public virtual Product Product { get; set; } = null!;
}

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public int CategoryId { get; set; }
    public virtual Category Category { get; set; } = null!;
}

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

Entity Relationships

- A Customer has many Orders

- An Order has many OrderItems

- Each OrderItem references one Product

- Each Product belongs to one Category

This creates a deep object graph: Customer → Orders → OrderItems → Products → Categories

Project setup

DbContext Configuration

public class SimplifiedECommerceDbContext : DbContext
{
    public SimplifiedECommerceDbContext(DbContextOptions options) 
        : base(options) { }
    
    public DbSet Customers => Set();
    public DbSet Orders => Set();
    public DbSet OrderItems => Set();
    public DbSet Products => Set();
    public DbSet Categories => Set();
}

Program.cs Setup

I will show here what’s important to setup in DI container:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenApi();

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");

services.AddDbContext(options =>
            options.UseLazyLoadingProxies()  // Enable lazy loading
                .UseSqlServer(connectionString)
                .EnableSensitiveDataLogging());

builder.Services.Configure(options =>
{
    options.SerializerOptions.ReferenceHandler = 
        System.Text.Json.Serialization.ReferenceHandler.IgnoreCycles;
});

Key point: Notice UseLazyLoadingProxies() - this enables lazy loading support. You’ll also need to install following Nuget package:

Microsoft.EntityFrameworkCore.Proxies

Important: The `ReferenceHandler.IgnoreCycles` configuration prevents JSON serialization errors when dealing with circular references in lazy-loaded entities.

Lazy loading

Lazy loading is the automatic loading of related entities when you access their navigation properties. It’s “lazy” because the data isn’t loaded until you actually need it.

When you access a navigation property (like `customer.Orders`), Entity Framework Core:

1. Detects the access

2. Generates and executes a SQL query

3. Loads the data

4. Returns it to you

public async Task> GetCustomersLazyAsync()
{
    Console.WriteLine("=== LAZY LOADING START ===");
    
    // Load customers only - no related data yet
    var customers = await _simplifiedECommerceDbContext.Customers
        .ToListAsync();
    
    Console.WriteLine($"Loaded {customers.Count} customers with full graph");
    
    // Accessing navigation properties triggers additional queries
    foreach (var customer in customers)
    {
        foreach (var order in customer.Orders)  // ← Query executed here
        {
            Console.WriteLine($"  Order {order.Id} ({order.CreatedAt})");

            foreach (var item in order.Items)  // ← Query executed here
            {
                // Accessing Product triggers another query
                Console.WriteLine(
                    $"Item {item.Id} | Product: {item.Product.Name} | Price: {item.Product.Price}");
            }
        }
    }
    
    Console.WriteLine("=== LAZY LOADING END ===");
    return customers;
}

SQL Queries Generated

For 10 customers with 5 orders each, and 5 items per order, this generates:

SELECT * FROM Customers                     -- 1 query

SELECT * FROM Orders WHERE CustomerId = 1   -- 10 queries (one per customer)

SELECT * FROM OrderItems WHERE OrderId = X  -- 50 queries (one per order)

SELECT * FROM Products WHERE Id = Y         -- 250 queries (one per item)

Total: 311 database queries! This is the N+1 problem.

Pros and Cons

✅ Pros:

- Simple to implement

- No need to specify `Include()`

- Only loads data you actually use

- Good for scenarios where related data is rarely accessed

❌ Cons:

- N+1 query problem - can cause hundreds or thousands of queries

- Poor performance for deep object graphs

- Requires `virtual` navigation properties

- Requires `UseLazyLoadingProxies()`

- Can cause issues with serialization

When to Use Lazy Loading

- Simple, shallow data structures

- When you rarely need related data

- Development/prototyping phase

- When database round-trips are cheap (same datacenter)

Eager Loading

Eager loading loads all related data upfront in a single query (or a few queries using split queries) using `Include()` and `ThenInclude()` methods.

You explicitly tell Entity Framework Core which related entities to load, and it generates an optimized SQL query with JOINs (or multiple parallel queries with split queries).

public async Task> GetCustomersEagerAsync()
{
    Console.WriteLine("=== EAGER LOADING START ===");
    
    // Load customers with ALL related data in one go
    var customers = await _simplifiedECommerceDbContext.Customers
        .Include(x => x.Orders)                    // Load orders
        .ThenInclude(x => x.Items)                 // Load items
        .ThenInclude(x => x.Product)               // Load products
        .ThenInclude(x => x.Category)              // Load categories
        .AsSplitQuery()                            // Use multiple queries instead of one huge JOIN
        .AsNoTracking()                            // Don't track changes for read-only data
        .ToListAsync();
    
    Console.WriteLine($"Loaded {customers.Count} customers with full graph");
    
    // All data is already loaded - no additional queries
    foreach (var customer in customers)
    {
        foreach (var order in customer.Orders)
        {
            Console.WriteLine($"  Order {order.Id} ({order.CreatedAt})");

            foreach (var item in order.Items)
            {
                Console.WriteLine(
                    $"Item {item.Id} | Product: {item.Product.Name} | Price: {item.Product.Price}");
            }
        }
    }
    
    Console.WriteLine("=== EAGER LOADING END ===");
    return customers;
}

SQL Queries generated:

With `AsSplitQuery()`, Entity Framework generates 5 separate queries that run in parallel:

-- Query 1: Get all customers
SELECT * FROM Customers

-- Query 2: Get all related orders
SELECT * FROM Orders WHERE CustomerId IN (1,2,3,...)

-- Query 3: Get all related order items
SELECT * FROM OrderItems WHERE OrderId IN (1,2,3,...)

-- Query 4: Get all related products
SELECT * FROM Products WHERE Id IN (1,2,3,...)

-- Query 5: Get all related categories
SELECT * FROM Categories WHERE Id IN (1,2,3,...)

Total: 5 queries instead of 311!

AsSplitQuery vs Single Query

Without `AsSplitQuery()`, EF Core generates one massive query with multiple JOINs, which can create a cartesian explosion - the result set can become enormous due to JOIN multiplication.

Example: 10 customers × 5 orders × 5 items = 250 rows returned for just 10 customers!

`AsSplitQuery()` solves this by breaking it into multiple queries.

AsNoTracking()

`AsNoTracking()` tells EF Core not to track changes to these entities. Use it for:

- Read-only operations

- API responses

- Better performance (no change tracking overhead)

Pros and Cons

✅ Pros:

- Optimal performance - minimal database round-trips

- Predictable query count

- No N+1 problem

- No need for `virtual` navigation properties

- Works without lazy loading proxies

- Best for API responses

❌ Cons:

- Can load unnecessary data if you don’t need everything

- More verbose code

- Need to know the object graph structure upfront

- Can cause cartesian explosion without split queries

When to Use Eager Loading

- API endpoints that return DTOs

- When you know you’ll need related data

- Performance-critical scenarios

- **Most common choice for production APIs**

Explicit Loading

Explicit loading gives you fine-grained control over what gets loaded and when. You manually load related entities using `Entry().Collection().LoadAsync()` or `Entry().Reference().LoadAsync()`.

You load the main entity first, then conditionally load related data based on business logic.

public async Task> GetCustomersExplicitAsync()
{
    Console.WriteLine("=== EXPLICIT LOADING START ===");

    // Load only customers first
    var customers = await _simplifiedECommerceDbContext.Customers.ToListAsync();

    foreach (var customer in customers)
    {
        // Only load orders for first 5 customers
        if (customer.Id <= 5)
        {
            await _simplifiedECommerceDbContext.Entry(customer)
                .Collection(x => x.Orders)
                .LoadAsync();
            
            foreach (var order in customer.Orders)
            {
                Console.WriteLine($"  Order {order.Id} ({order.CreatedAt})");
                
                // Load items for each order
                await _simplifiedECommerceDbContext.Entry(order)
                    .Collection(o => o.Items)
                    .LoadAsync();

                foreach (var item in order.Items)
                {
                    // Only load product details for items with quantity >= 3
                    if (item.Quantity >= 3)
                    {
                        await _simplifiedECommerceDbContext.Entry(item)
                            .Reference(x => x.Product)
                            .LoadAsync();
                        
                        Console.WriteLine(
                            $"Item {item.Id} | Product: {item.Product.Name} | Price: {item.Product.Price}");
                    }
                }
            }
        }
    }
    
    Console.WriteLine("=== EXPLICIT LOADING END ===");
    return customers;
}

Key methods

- `Entry(entity)` - Gets the entry for tracking and loading

- `.Collection(x => x.Property)` - Loads a collection navigation property (1-to-many)

- `.Reference(x => x.Property)` - Loads a reference navigation property (1-to-1 or many-to-1)

- `.LoadAsync()` - Executes the load operation

Use Case: Conditional Loading

In the example above:

- Orders are only loaded for customers 1-5

- Product details are only loaded for items with quantity ≥ 3

This is useful when:

- You have conditional business logic

- Different users see different data (permissions)

- You want to optimize based on data characteristics

Pros and Cons

✅ Pros:

- **Maximum control** over what gets loaded

- Conditional loading based on business logic

- Can optimize for specific scenarios

- No unnecessary data loaded

- Good for complex permission/filtering logic

❌ Cons:

- Most verbose approach

- Requires more code

- Easy to introduce N+1 if not careful

- Harder to maintain

- Requires understanding of EF Core entry API

When to Use Explicit Loading

- Complex permission-based filtering

- Conditional data loading based on business rules

- Scenarios where eager loading would load too much

- When you need surgical control over queries

Key Takeaways

1. Lazy Loading - Automatic but causes N+1 problems

2. Eager Loading - Optimal for APIs (5 queries with split query)

3. Explicit Loading - Maximum control for conditional scenarios

4. Use `AsSplitQuery()` - Prevents cartesian explosion

5. Use `AsNoTracking()` - Better performance for read-only operations

For most production APIs, Eager Loading with Split Queries is the winner.

YouTube

Minimal API Validation in .NET 10 - Built-In Support with Data Annotations

Remigiusz Zalewski — Sat, 07 Feb 2026 07:01:31 GMT

Introduction

If you’ve ever built a Minimal API in .NET, you probably know the pain - there was no built-in validation out of the box.

You had to rely on third-party libraries like FluentValidation or write manual checks inside your endpoint handlers.

That changes with .NET 10.

Microsoft has introduced native validation support for Minimal APIs using Data Annotations - the same [Required], [MaxLength], and custom validation attributes you already know from MVC controllers.

In this article, I’ll walk you through exactly how it works using a practical Library API example.

🎬 Watch the full video here:

The Problem Before .NET 10

In earlier versions of .NET, Minimal APIs had no automatic model validation. If you defined a POST endpoint like this:

app.MapPost("/books", (CreateBookRequest request) =>
{
    // No validation happens automatically!
    // You had to manually check or use FluentValidation
});

The framework would happily accept any payload - even an empty one - and let your handler deal with it.

This meant:

❌ No automatic 400 Bad Request responses
❌ No support for [Required], [MaxLength], etc.
❌ Extra libraries or boilerplate validation logic

What’s New in .NET 10

.NET 10 adds a single line that changes everything:

builder.Services.AddValidation();

That’s it.

By calling AddValidation() on your service collection, the framework will automatically validate any request model decorated with Data Annotation attributes before your endpoint handler executes.

If validation fails, the API returns a 400 Bad Request with detailed error messages — no manual intervention required.

Full Example - Building a “Library API”

Let’s build a simple Library API that validates book creation requests.

1. Project Setup

Make sure you’re targeting .NET 10:



  
    net10.0
    enable
    enable

2. Define the Request Model with Validation

This is where the magic happens.

using System.ComponentModel.DataAnnotations;

namespace LibraryApi;

public record CreateBookRequest(
    [Required]
    [MinLength(2)]
    [MaxLength(200)]
    string Title,

    [Required]
    string Author,

    string? Isbn,

    [ValidPublishedYear]
    int? PublishedYear
);

What’s happening here?

Title is required and must be between 2 and 200 characters
Author is required
Isbn is optional
PublishedYear uses a custom validation attribute

3. Create a Custom Validation Attribute

For scenarios where built-in attributes aren’t enough, you can create your own.

using System.ComponentModel.DataAnnotations;

namespace LibraryApi;

[AttributeUsage(AttributeTargets.Parameter)]
public sealed class ValidPublishedYearAttribute : ValidationAttribute
{
    private const int MinYear = 1450;

    protected override ValidationResult? IsValid(
        object? value,
        ValidationContext validationContext)
    {
        if (value is null)
            return ValidationResult.Success;

        if (value is not int year)
            return new ValidationResult("Published year must be a number.");

        var currentYear = DateTime.UtcNow.Year;

        if (year < MinYear || year > currentYear)
        {
            return new ValidationResult(
                $"Published year must be between {MinYear} and {currentYear}.");
        }

        return ValidationResult.Success;
    }
}

Key details

✅ null is allowed - the field is optional
✅ The year must be within a sensible range
✅ Inherits from ValidationAttribute
⚠️ [AttributeUsage(AttributeTargets.Parameter)] is required because record constructor members are parameters, not properties

4. Define the Response DTO

namespace LibraryApi;

public record BookDto(
    Guid Id,
    string Title,
    string Author,
    string? Isbn,
    int? PublishedYear
);

5. Wire Everything in `Program.cs`

using LibraryApi;
using Scalar.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenApi();
builder.Services.AddValidation();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
    app.MapScalarApiReference();
}

app.UseHttpsRedirection();

app.MapPost("/books", (CreateBookRequest request) =>
{
    var createdBook = new BookDto(
        Guid.NewGuid(),
        request.Title,
        request.Author,
        request.Isbn,
        request.PublishedYear
    );

    return Results.Created($"/books/{createdBook.Id}", createdBook);
})
.WithName("CreateBook");

app.Run();

📌 The only new line compared to classic Minimal APIs is:

builder.Services.AddValidation();

How It Works Under the Hood

When you call AddValidation():

Request arrives → JSON is deserialized into your record
Validation filter runs → Data Annotations are evaluated
Valid → endpoint executes
Invalid → pipeline short-circuits and returns 400 Bad Request

No ModelState, no manual checks, no boilerplate.

Testing the Validation

✅ Valid Request

POST /books
{
  "title": "Clean Code",
  "author": "Robert C. Martin",
  "isbn": "978-0132350884",
  "publishedYear": 2008
}

Response: 201 Created

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "title": "Clean Code",
  "author": "Robert C. Martin",
  "isbn": "978-0132350884",
  "publishedYear": 2008
}

❌ Missing Required Fields

POST /books
{
  "isbn": "978-0132350884"
}

Response: 400 Bad Request
Validation errors for title and author

❌ Title Too Short

POST /books
{
  "title": "A",
  "author": "John Doe"
}

Response: 400 Bad Request

❌ Future Published Year

POST /books
{
  "title": "Future Book",
  "author": "Time Traveler",
  "publishedYear": 2999
}

Response: 400 Bad Request

Key Takeaways

.NET 10 adds first-class validation for Minimal APIs
One line: builder.Services.AddValidation()
Standard Data Annotations just work
Custom validation is fully supported
Automatic 400 responses with Problem Details
No third-party libraries required

This is a major quality-of-life improvement for Minimal APIs.
What used to require FluentValidation or manual checks now works out of the box.

YouTube

AddSingleton vs AddScoped vs AddTransient in ASP.NET Core Dependency Injection

Remigiusz Zalewski — Sat, 31 Jan 2026 07:01:15 GMT

Introduction

When building modern ASP .NET Core applications, Dependency Injection (DI) is a key design pattern that helps you write clean, maintainable, and testable code.
But one question often confuses developers:

❓ What’s the difference between AddSingleton, AddScoped, and AddTransient in ASP .NET Core?

In this article, we’ll break down each service lifetime, explain when to use which, and provide real C# examples you can copy and paste into your projects.

What Is Dependency Injection?

Dependency Injection is a technique where the framework automatically provides (injects) instances of required services into your classes.

In ASP .NET Core, you register services in the DI container (usually in Program.cs) like this:

builder.Services.AddSingleton();
builder.Services.AddScoped();
builder.Services.AddTransient();

But what’s the difference?

Each of these methods defines how long the created service instance should live — in other words, its lifetime.

🧩 AddSingleton - One Instance for the Entire Application

A Singleton service is created once and shared across the entire application lifetime.

That means:

The same instance is reused for every request and every dependency.
The instance lives until the application stops.

✅ When to use AddSingleton

Use AddSingleton for:

Stateless services
Configuration providers
Logging
Caching layers

❌ Avoid when

The service holds request-specific data
The service depends on a scoped or transient dependency

💡 Example

public interface IGuidService
{
    string GetGuid();
}

public class SingletonGuidService : IGuidService
{
    private readonly string _guid;

    public SingletonGuidService()
    {
        _guid = Guid.NewGuid().ToString();
    }

    public string GetGuid() => _guid;
}

// In Program.cs
builder.Services.AddSingleton();

Each time you request IGuidService, you get the same instance and the same GUID value.

🌐 AddScoped – One Instance per HTTP Request

AddScoped creates one instance per HTTP request.
All components handling that same request share the same instance, but a new instance is created for each new request.

This makes it ideal for request-specific data and database operations.

✅ Best For

Database contexts (DbContext in Entity Framework Core)
Unit of Work pattern
Request-specific data (services, repositories)

💡 Example

public interface IRequestService
{
    Guid GetRequestId();
}

public class RequestService : IRequestService
{
    private readonly Guid _requestId = Guid.NewGuid();
    public Guid GetRequestId() => _requestId;
}

// Register in Program.cs
builder.Services.AddScoped();

// Example controller
[ApiController]
[Route("api/[controller]")]
public class ScopedExampleController : ControllerBase
{
    private readonly IRequestService _service1;
    private readonly IRequestService _service2;

    public ScopedExampleController(IRequestService service1, IRequestService service2)
    {
        _service1 = service1;
        _service2 = service2;
    }

    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new
        {
            FirstInstance = _service1.GetRequestId(),
            SecondInstance = _service2.GetRequestId()
        });
    }
}

🧠 What you’ll see:

Within the same HTTP request, both FirstInstance and SecondInstance will return the same GUID. When you make another request, a new GUID will appear — confirming a new instance was created.

⚡ AddTransient - A New Instance Every Time

An AddTransient service is created each time it’s requested from the Dependency Injection (DI) container.

Let’s imagine you’re building an email notification system in your ASP.NET Core application.
You might have a lightweight EmailFormatter service that prepares email content before it’s sent.

This service:

Doesn’t store state
Performs quick, one-off operations
Should be short-lived (you don’t want to reuse old email content or data)

That means:

Every injection or method call gets a brand new object.
This is ideal for lightweight, stateless, and non-expensive services.

✅ When to Use AddTransient

Use AddTransient for:

Utility or helper classes
Small operations
Short-lived, non-expensive services

❌ Avoid When

The service performs expensive initialization
The service holds shared state or data that needs to persist between calls

💡 Example

public interface IEmailFormatter
{
    string FormatWelcomeEmail(string userName);
}

public class EmailFormatter : IEmailFormatter
{
    public string FormatWelcomeEmail(string userName)
    {
        return $"Hi {userName}, welcome to our platform! 🎉";
    }
}

// Program.cs
builder.Services.AddTransient();

🚀 Why AddTransient Works Here

Each email send operation gets a fresh EmailFormatter. No state is reused between emails. It’s lightweight, stateless, and safe to recreate on demand.

🧠 Key Takeaways

Choose Singleton for shared, thread-safe, stateless services.
Choose Scoped for request-level services (like DbContext).
Choose Transient for lightweight, short-lived dependencies.
Correct use of lifetimes ensures performance, stability, and predictable behavior in your ASP.NET Core applications.

Factory Design Pattern in C#

Remigiusz Zalewski — Sat, 24 Jan 2026 07:00:28 GMT

Introduction

In the ever-changing world of software development, design patterns act as guides to efficiency and good practices. These well-tested answers to common coding challenges have become essential tools for developers.

They offer a organized way to build strong, expandable, and easy-to-maintain software systems. Design patterns aren’t strict rules. Instead, they’re flexible templates that can be adjusted to solve recurring design issues in different situations. They capture the shared knowledge of seasoned software engineers, creating a common language that works across different programming languages and technologies.

The Factory Pattern in C# is a creational design pattern that provides a way to create objects without specifying the exact class of object that will be created. This pattern is particularly useful in scenarios where the instantiation logic is complex or varies based on certain conditions. In this article, we will explore an example of using the Factory Pattern to create invoices in different formats based on a provided document type.

Let’s first examine the code below, which does not use the Factory Pattern, and highlight its drawbacks in terms of violating SOLID principles and clean code practices:

app.MapGet("/api/invoice/{id}/{format}", (Guid id, InvoiceFormat format) =>
{
    var generator = new InvoiceGenerator();
    var invoiceData = generator.GenerateInvoice(id, format);
    var contentType = generator.GetContentType(format);

    string fileName = $"Invoice_{id}.{format.ToString().ToLower()}";

    return Results.File(invoiceData, contentType, fileName);
})
.WithName("GenerateInvoice")
.WithOpenApi();

public class InvoiceGenerator
{
    public byte[] GenerateInvoice(Guid invoiceId, string format)
    {
        var invoice = MockInvoiceProvider.CreateMockInvoice(invoiceId);
        format = format.ToLower();

        switch (format)
        {
            case "pdf":
                return GeneratePdfInvoice(invoice);
            case "txt":
                return GenerateTxtInvoice(invoice);
            case "csv":
                return GenerateCsvInvoice(invoice);
            default:
                throw new ArgumentException("Invalid format", nameof(format));
        }
    }

    public string GetContentType(string format)
    {
        format = format.ToLower();

        switch (format)
        {
            case "pdf":
                return "application/pdf";
            case "txt":
                return "text/plain";
            case "csv":
                return "text/csv";
            default:
                throw new ArgumentException("Invalid format", nameof(format));
        }
    }
}

Violation of the Single Responsibility Principle (SRP): The InvoiceGenerator class is responsible for too many things: fetching invoice data, determining content types, and generating invoices in multiple formats. This makes the class harder to maintain and extend.
Open/Closed Principle (OCP) Violation: The switch statements in both GenerateInvoice and GetContentType violate OCP because adding a new format (e.g., JSON or XML) requires modifying these methods. This increases the risk of introducing bugs and makes the code less extensible.
Tight Coupling: The InvoiceGenerator class is tightly coupled to specific invoice generation logic (GeneratePdfInvoice, GenerateTxtInvoice, etc.). This makes it difficult to test or replace individual components without affecting the entire class.
Code Duplication: The switch statement logic is duplicated across methods (GenerateInvoice and GetContentType). This redundancy increases maintenance overhead and can lead to inconsistencies if one part is updated but not the other.
Lack of Scalability: As more formats are added, the class becomes bloated with additional cases in the switch statements, making it harder to read and maintain.

Let’s refactor the code to apply the Factory design pattern step-by-step and examine the benefits we achieve:

Define the invoice generator interface: All types of formats are using two methods: GenerateInvoice and GetContentType . We can create an interface called IInvoiceGenerator that later on could be implemented by concrete classes.

public interface IInvoiceGenerator
{
    byte[] GenerateInvoice(Guid invoiceId);
    string GetContentType();
}

Create Concrete Classes: Now I will create three classes — PdfInvoiceGenerator , TxtInvoiceGenerator and CsvInvoiceGenerator that will implement IInvoiceGenerator interface and it will generate the invoice based on their format. At the same time I will remove the InvoiceGenerator class (as it won’t be needed anymore).

public class PdfInvoiceGenerator : IInvoiceGenerator
{
    public byte[] GenerateInvoice(Guid invoiceId)
    {
        var invoice = MockInvoiceProvider.CreateMockInvoice(invoiceId);

        var document = Document.Create(container =>
        {
            container.Page(page =>
            {
                page.Size(PageSizes.A4);
                page.Margin(2, Unit.Centimetre);
                page.Header().Text($"Invoice #{invoice.Id}").SemiBold().FontSize(20);
                page.Content().PaddingVertical(1, Unit.Centimetre).Column(column =>
                {
                    column.Item().Text($"Date: {invoice.Date:yyyy-MM-dd}");
                    column.Item().Text($"Customer: {invoice.CustomerName}");
                    column.Item().Text($"Amount: ${invoice.Amount:F2}").FontSize(14);
                });
                page.Footer().AlignCenter().Text(x =>
                {
                    x.Span("Page ");
                    x.CurrentPageNumber();
                });
            });
        });

        return document.GeneratePdf();
    }

    public string GetContentType() => "application/pdf";
}

public class TxtInvoiceGenerator : IInvoiceGenerator
{
    public byte[] GenerateInvoice(Guid invoiceId)
    {
        var invoice = MockInvoiceProvider.CreateMockInvoice(invoiceId);

        string content = $"Invoice #{invoice.Id}\n" +
                         $"Date: {invoice.Date:yyyy-MM-dd}\n" +
                         $"Customer: {invoice.CustomerName}\n" +
                         $"Amount: ${invoice.Amount:F2}";

        return Encoding.UTF8.GetBytes(content);
    }

    public string GetContentType() => "text/plain";
}

public class CsvInvoiceGenerator : IInvoiceGenerator
{
    public byte[] GenerateInvoice(Guid invoiceId)
    {
        var invoice = MockInvoiceProvider.CreateMockInvoice(invoiceId);

        string csvContent = "Invoice ID,Date,Customer,Amount\n" +
                            $"{invoice.Id},{invoice.Date:yyyy-MM-dd},{invoice.CustomerName},{invoice.Amount:F2}";

        return Encoding.UTF8.GetBytes(csvContent);
    }

    public string GetContentType() => "text/csv";
}

Define enum to cover the supported invoice formats: I will get rid of handling the string as an input and make it more concise:

public enum InvoiceFormat
{
    Pdf,
    Txt,
    Csv
}

Define the factory class interface: I will define the IInvoiceGeneratorFactory interface that will be implemented later on by concrete factory class

public interface IInvoiceGeneratorFactory
{
    IInvoiceGenerator CreateInvoiceGenerator(InvoiceFormat invoiceFormat);
}

Create Factory class: After completion of all the steps we are ready to create the class that will implement the IInvoiceGeneratorFactory interface and based on InvoiceFormat enum that I have created, will decide which InvoiceGenerator class will return as the result

public class InvoiceGeneratorFactory : IInvoiceGeneratorFactory
{
    public IInvoiceGenerator CreateInvoiceGenerator(InvoiceFormat invoiceFormat)
    {
        return invoiceFormat switch
        {
            InvoiceFormat.Pdf => new PdfInvoiceGenerator(),
            InvoiceFormat.Txt => new TxtInvoiceGenerator(),
            InvoiceFormat.Csv => new CsvInvoiceGenerator(),
            _ => throw new ArgumentException("Invalid/Unsupported InvoiceFormat", nameof(invoiceFormat))
        };
    }
}

You can register your classes in DI container and resolve the dependencies using IServiceProvider to return the concrete class from the container instead of creating the class with the new operator:

public class InvoiceGeneratorFactory : IInvoiceGeneratorFactory
{
    private readonly IServiceProvider _serviceProvider;

    public InvoiceGeneratorFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IInvoiceGenerator CreateInvoiceGenerator(InvoiceFormat invoiceFormat)
    {
        return invoiceFormat switch
        {
            InvoiceFormat.Pdf => _serviceProvider.GetRequiredService(),
            InvoiceFormat.Txt => _serviceProvider.GetRequiredService(),
            InvoiceFormat.Csv => _serviceProvider.GetRequiredService(),
            _ => throw new ArgumentException("Invalid/Unsupported InvoiceFormat", nameof(invoiceFormat))
        };
    }
}

Register factory class in DI container: We need to register our factory class together with an interface to inject it to the place where it will be used (here minimal api endpoint)

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton();

Finally we can use our factory in the minimal api endpoint as follows:

app.MapGet("/api/invoice/{id}/{format}", (Guid id, InvoiceFormat format,
        IInvoiceGeneratorFactory invoiceGeneratorFactory) =>
{
    var generator = invoiceGeneratorFactory.CreateInvoiceGenerator(format);
    var invoiceData = generator.GenerateInvoice(id);
    var contentType = generator.GetContentType();

    string fileName = $"Invoice_{id}.{format.ToString().ToLower()}";

    return Results.File(invoiceData, contentType, fileName);
})
.WithName("GenerateInvoice")
.WithOpenApi();

Now we don’t need to pass the invoice format to the main InvoiceGenerator class, because the InvoiceGeneratorFactory class based on the format will return for us the concrete class that handles only this specific invoice format.

Summary

Applying the Factory Pattern addresses these issues by delegating object creation to a dedicated factory class. Here’s how it helps:

Adherence to Single Responsibility Principle: The responsibility for creating specific invoice formats is moved out of InvoiceGenerator class, allowing it to focus solely on orchestrating invoice generation.
Compliance with Open/Closed Principle: New formats can be added by creating new classes that implement a common interface (e.g., IInvoiceGenerator) without modifying existing code.
Improved Testability: Each format-specific logic is encapsulated in its own class, making unit testing more straightforward.
Reduced Code Duplication: The factory centralizes format handling logic, eliminating redundant switch statements.
Enhanced Maintainability: The separation of concerns makes it easier to understand, extend, and modify individual parts of the codebase.

By refactoring this code with the Factory Pattern, we can create a cleaner, more modular design that adheres to SOLID principles and other clean code practices.

Remigiusz Zalewski

EF Core Database First: Scaffold a DB Context from an Existing Database

Connect with me:

Introduction

The Starting Point: An Existing Database

Required NuGet Packages

The Scaffold Command

Understanding the Generated DbContext

Example entity created in Entities directory

The partial Class and OnModelCreatingPartial

The Two Constructors

virtual DbSet Properties

OnConfiguring

OnModelCreating - The Real Value

partial void OnModelCreatingPartial

Cleaning Up After Scaffolding

Move the DbContext Up One Level

Remove OnConfiguring and Move the Connection String

Querying with the Scaffolded Context

Pros and Cons of Database First Scaffolding

Pros

Cons

When to Use Database First

Key Takeaways

Connect with me:

Refit - The Better Way to Consume APIs in .NET

Connect with me:

Introduction

Setting Up the Project

Approach 1: Typed HttpClient with IHttpClientFactory

Configuration and Options

The Service and Interface

The Delegating Handler

Registering Everything in Program.cs

Approach 2: Refit

The Interface

Registration

What Refit Generates

When to Use Typed HttpClient

When to Use Refit

Key Takeaways

Resources

Connect with me:

EF Core Stored Procedures: Complete Guide for .NET Developers

Connect with me:

Introduction

The Starting Point

What Are Stored Procedures and When to Use Them

Creating Stored Procedures in EF Core Migrations

Creating a Blank Migration

Writing the Migration

A Procedure with Parameters

⚡ Calling Stored Procedures from Minimal API Endpoints

FromSqlRaw - No Parameters

FromSqlInterpolated - Parameterized Queries

ExecuteSqlInterpolatedAsync - Commands (No Return Value)

The Full BooksStoredProcedureModule

Migrations Keep Everything in Sync

Key Takeaways

Connect with me:

EF Core Performance: N+1, Cartesian Explosion and How to Fix Both

Connect with me:

Introduction

🐢 The N+1 Problem

Fix 1: Projections

When Projections Break Down

Fix 2: Eager Loading

⚡ Fix 3: AsSplitQuery

Trade-offs to Know

Key Takeaways

Connect with me

How to Set Up a Release Pipeline for ASP.NET Core in Azure DevOps

Connect with me:

Introduction

⚙️ Provisioning the Azure Virtual Machine

🌐 Enabling IIS and Installing the .NET Hosting Bundle

Enable IIS

Install the .NET Hosting Bundle

🔗 Connecting the VM to Azure DevOps via a Deployment Group

🚀 Building the Release Pipeline

The `partial` Class and `OnModelCreatingPartial`

`virtual` DbSet Properties

`OnConfiguring`

`OnModelCreating` - The Real Value

`partial void OnModelCreatingPartial`

Remove `OnConfiguring` and Move the Connection String

`FromSqlRaw` - No Parameters

`FromSqlInterpolated` - Parameterized Queries

`ExecuteSqlInterpolatedAsync` - Commands (No Return Value)

The Full `BooksStoredProcedureModule`