DEV Community: Anton Martyniuk

EF Core in Clean Architecture the Pragmatic Way

Anton Martyniuk — Mon, 19 Oct 2026 04:34:47 +0000

Clean Architecture is one of the most popular architectural styles in .NET today.

Clean Architecture aims to separate the application's concerns into distinct layers, promoting high cohesion and low coupling.

In the classic implementation you need to hide EF Core behind a Repository so the Application layer never depends on the ORM.

I followed that advice for years.
But after many production projects, I changed my mind and adopted a more pragmatic approach to implementing Clean Architecture.

In this post, I want to explain why I no longer wrap EF Core in a repository inside Clean Architecture, and why I think most teams should do the same.
We will look at what the original Clean Architecture really says and how a pragmatic approach keeps the same boundaries in the code.

In this post, we will explore:

The Traditional Clean Architecture with a Repository
The Hidden Cost of Repositories in Clean Architecture
Pragmatic Clean Architecture: Use EF Core Directly in Application Use Cases
What if We Switch a Database Later?
When You Might Still Need a Custom Repository

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-in-clean-architecture-the-pragmatic-way

The Traditional Clean Architecture with a Repository

Clean Architecture splits an application into four layers, each with a clear role:

Domain — entities, value objects, and core business rules.
Application — use cases, commands, queries, and handlers.
Infrastructure — implementations of external concerns: database, cache, message bus, email, identity provider.
Presentation — the entry point: Web API, gRPC, GraphQL, MVC, Blazor, etc.

The key rule is the Dependency Rule: dependencies point inwards:

Domain knows nothing about other layers
Application depends only on the Domain.
Infrastructure and Presentation depend on Application and Domain.

In the traditional setup, the Application layer defines the Repository contract:

public interface IShipmentRepository
{
    Task<Shipment?> GetByIdAsync(Guid id, CancellationToken cancellationToken);
    Task<bool> ExistsForOrderAsync(string orderId, CancellationToken cancellationToken);
    Task AddAsync(Shipment shipment, CancellationToken cancellationToken);
}

public interface IUnitOfWork
{
    Task<int> SaveChangesAsync(CancellationToken cancellationToken);
}

Infrastructure implements it on top of EF Core:

internal sealed class ShipmentRepository(ShipmentsDbContext context) : IShipmentRepository
{
    public Task<Shipment?> GetByIdAsync(Guid id, CancellationToken cancellationToken)
        => context.Shipments
            .Include(x => x.Items)
            .FirstOrDefaultAsync(x => x.Id == id, cancellationToken);

    public Task<bool> ExistsForOrderAsync(string orderId, CancellationToken cancellationToken)
        => context.Shipments.AnyAsync(x => x.OrderId == orderId, cancellationToken);

    public async Task AddAsync(Shipment shipment, CancellationToken cancellationToken)
        => await context.Shipments.AddAsync(shipment, cancellationToken);
}

internal sealed class UnitOfWork(ShipmentsDbContext context) : IUnitOfWork
{
    public Task<int> SaveChangesAsync(CancellationToken cancellationToken)
        => context.SaveChangesAsync(cancellationToken);
}

A use case handler injects the abstractions:

internal sealed class CreateShipmentHandler(
    IShipmentRepository repository,
    IUnitOfWork unitOfWork,
    ILogger<CreateShipmentHandler> logger)
{
    public async Task<Result<ShipmentResponse>> HandleAsync(
        CreateShipmentCommand command,
        CancellationToken cancellationToken)
    {
        var exists = await repository.ExistsForOrderAsync(command.OrderId, cancellationToken);
        if (exists)
        {
            return ShipmentErrors.AlreadyExists(command.OrderId);
        }

        var shipment = command.MapToShipment();

        await repository.AddAsync(shipment, cancellationToken);
        await unitOfWork.SaveChangesAsync(cancellationToken);

        return shipment.MapToResponse();
    }
}

The Dependency Rule is satisfied, and you can switch the implementation in tests. So far, so good.
But...

The Hidden Cost of Repositories in Clean Architecture

I have built many systems with this pattern. Here is what tends to happen as the project grows.

1. A repository is an abstraction over an abstraction.

EF Core's DbContext already implements both the Repository pattern and the Unit of Work pattern.
This is stated in the official DbContext summary. When you put IShipmentRepository on top of it, you are wrapping a wrapper.

When we create a repository over EF Core, we create an abstraction over an abstraction, leading to over-engineered solutions.

Each DbSet<TEntity> in your DbContext represents a collection of entities, just like a typical repository.

It allows you to:

Query data using LINQ
Add, update, and remove entities
Project data to other types

2. Method explosion.

What starts as four methods becomes 20:

public interface IShipmentRepository
{
    Task<Shipment?> GetByIdAsync(...);
    Task<List<Shipment>> GetByOrderIdAsync(...);
    Task<List<Shipment>> GetByCarrierAsync(...);
    Task<List<Shipment>> GetActiveAsync(...);
    Task<List<Shipment>> GetByStatusAsync(...);
    Task<List<Shipment>> GetCreatedBetweenAsync(...);
    Task<List<Shipment>> GetWithItemsAsync(...);
    // ... many more
}

Every new feature adds a new method.
After a year, no one knows whether the method they need already exists, so they add another one that does almost the same thing.

3. Cross-entity queries have no right place.

What if a feature needs a shipment, its order, plus the customer's address?
Where does that method live? IShipmentRepository? IOrderRepository? A new IShipmentOrderRepository?

4. Includes and projections leak or duplicate.

Some callers need Include(x => x.Items), some do not.
Some want a ShipmentResponse projection, and some want the full entity.
You end up with GetByIdWithItemsAsync, GetByIdSlimAsync, GetByIdForReportAsync — or you load too much data on every call.

5. Mocked-repository tests give false confidence.

Mocking IShipmentRepository is fast, but it does not test how EF Core translates your LINQ-to-SQL queries, whether your Include clauses work, or whether your database uniqueness constraints are enforced.
The exact things that break in production.

6. Slower feature delivery.

Every new use case touches three files: the repository interface, the repository implementation, and the handler.
For a single new query, that is a lot of ceremony.

Now, let's look at a pragmatic approach to using EF Core in Clean Architecture.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-in-clean-architecture-the-pragmatic-way

How to Structure Production Apps with Vertical Slice Architecture in .NET in 2026

Anton Martyniuk — Sat, 17 Oct 2026 08:16:35 +0000

Vertical Slice Architecture (VSA) is one of the most popular ways to structure .NET projects today.

It structures an application by features instead of technical layers.

In a traditional layered project, you have a Controllers folder, a Services folder, and a Repositories folder (and probably way more).
To change one feature, you jump between three or four folders (or even projects).

In VSA, every feature is a single slice.
The endpoint, business logic, validation, and data access for that feature live next to each other.

This brings several benefits:

High cohesion within a feature
Loose coupling between features
Faster navigation in the codebase
Independent changes to one feature do not take effect on the others

I have built many systems with VSA and shipped them to production, and over the years, my layout has settled into a single shape that I now reuse in every new project.

In this post, we will explore:

How I Structure my Projects with Vertical Slice Architecture
The Shared folder within a module
Auto-registration of endpoints, and handlers
Cross-slice side effects via events
Inter-module communication via PublicApi

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-structure-production-apps-with-vertical-slice-architecture-in-dotnet-in-2026

How I Structure my Projects with Vertical Slice Architecture

There are many ways to structure a slice.
In all of them, each vertical slice is placed in its own folder named after the use case.

Here are the most popular ones:

1. Each class for a feature is in a separate file name

2. Single file per slice with nested classes

public static class CreateShipment
{
    public sealed record Request(...);

    public sealed record Response(...);

    public class Validator : AbstractValidator<Request> { }

    public static void MapEndpoint(WebApplication app)
    {
        app.MapPost("/api/shipments", Handle);
    }

    private static async Task<IResult> Handle() { }
}

3. Separate file with each concern

This code structure combines the advantages of the first two options:

You put the request and response modules together in the endpoint file
You don't have too many files, as concerns are separated
You don't have a static file that nests other classes

This is the exact approach I use in production.

Each slice is a folder named after the use case.
Inside the folder, I keep four files, each focused on one concern.

For the "Create Shipment" use case, the layout looks like this:

Features/
└── CreateShipment/
    ├── CreateShipment.Endpoint.cs
    ├── CreateShipment.Handler.cs
    ├── CreateShipment.Mapping.cs
    └── CreateShipment.Validators.cs

When a slice raises events that other modules react to, I add an Events subfolder:

Features/
└── CreateShipment/
    ├── CreateShipment.Endpoint.cs
    ├── CreateShipment.Handler.cs
    ├── CreateShipment.Mapping.cs
    ├── CreateShipment.Validators.cs
    └── Events/
        ├── ShipmentCreatedEvent.cs
        ├── UpdateStockEventHandler.cs
        └── CreateCarrierEventHandler.cs

The naming convention uses a dot suffix: {Slice}.Endpoint.cs, {Slice}.Handler.cs, and so on.
This keeps files easy to find in the IDE search and easy to scan in the file tree.

I also extract cross-cutting concerns, such as validators and mappers, into separate files, so I don't clutter the main file with too many classes.

The Endpoint File

The endpoint file contains the request, response records and the Minimal API endpoint class.

The endpoint is responsible for:

Parsing the HTTP request
Running validation
Calling the handler
Translating the handler result into an HTTP response

Here is CreateShipment.Endpoint.cs:

public sealed record CreateShipmentRequest(
    string OrderId,
    Address Address,
    string Carrier,
    string ReceiverEmail,
    List<ShipmentItemRequest> Items);

public class CreateShipmentApiEndpoint : IApiEndpoint
{
    public void MapEndpoint(WebApplication app)
    {
        app.MapPost(RouteConsts.BaseRoute, Handle);
    }

    private static async Task<IResult> Handle(
        [FromBody] CreateShipmentRequest request,
        IValidator<CreateShipmentRequest> validator,
        ICreateShipmentHandler handler,
        CancellationToken cancellationToken)
    {
        var validationResult = await validator.ValidateAsync(request, cancellationToken);
        if (!validationResult.IsValid)
        {
            return Results.ValidationProblem(validationResult.ToDictionary());
        }

        var response = await handler.HandleAsync(request, cancellationToken);
        if (response.IsError)
        {
            return response.Errors.ToProblem();
        }

        return Results.Ok(response.Value);
    }
}

The endpoint class implements a small marker interface called IApiEndpoint:

public interface IApiEndpoint
{
    void MapEndpoint(WebApplication app);
}

This interface lets me discover and register all endpoints in a single line at startup (more on that later).

response.Errors.ToProblem() is an extension method that maps error types (Conflict, NotFound, Validation, and so on) to the appropriate HTTP status codes.

Validation runs explicitly in the endpoint, before the handler is called.
I do not use a MediatR pipeline behavior, like in many implementations.
The validation flow stays simple and easy to follow.

The Handler File

I implement the business logic inside the Handler class.

I use a manual handler pattern, which is a simple class without an interface.

I do not use MediatR. Instead, I have a small marker interface called IHandler:

public interface IHandler;

Every handler class in the project extends IHandler.
This lets me auto-register handlers with assembly scanning.

Here is CreateShipment.Handler.cs:


internal sealed class CreateShipmentHandler(
    ShipmentsDbContext context,
    IStockModuleApi stockApi,
    IEventPublisher eventPublisher,
    ILogger<CreateShipmentHandler> logger)
    : IHandler
{
    public async Task<Result<ShipmentResponse>> HandleAsync(
        CreateShipmentRequest request,
        CancellationToken cancellationToken)
    {
        var shipmentExists = await context.Shipments
            .AnyAsync(x => x.OrderId == request.OrderId, cancellationToken);

        if (shipmentExists)
        {
            logger.LogInformation("Shipment for order '{OrderId}' already exists", request.OrderId);
            return ShipmentErrors.AlreadyExists(request.OrderId);
        }

        var stockRequest = CreateCheckStockRequest(request);

        var stockResponse = await stockApi.CheckStockAsync(stockRequest, cancellationToken);
        if (!stockResponse.IsSuccess)
        {
            logger.LogInformation("Stock check failed: {@Errors}", stockResponse.Errors);
            return stockResponse.Errors;
        }

        var shipmentNumber = new Faker().Commerce.Ean8();
        var shipment = request.MapToShipment(shipmentNumber);

        await context.Shipments.AddAsync(shipment, cancellationToken);
        await context.SaveChangesAsync(cancellationToken);

        logger.LogInformation("Created shipment: {@Shipment}", shipment);

        var shipmentCreatedEvent = new ShipmentCreatedEvent(shipment);
        await eventPublisher.PublishAsync(shipmentCreatedEvent, cancellationToken);

        return shipment.MapToResponse();
    }

    private static CheckStockRequest CreateCheckStockRequest(CreateShipmentRequest request)
    {
        return new CheckStockRequest(
            request.Items
                .Select(x => new ProductStock(x.Product, x.Quantity))
                .ToList()
        );
    }
}

Notice how simple the structure is.
No extra interfaces, no commands, no command handlers, no mediator, no magic navigation to implementation, just a direct call to an exact class.

Instead of throwing exceptions for expected errors, the handler uses a Result Pattern and returns Result<ShipmentResponse>.

Errors for the module live in a single static class, so they stay consistent and easy to find:

internal static class ShipmentErrors
{
    private const string ErrorPrefix = "Shipments";

    internal static Error NotFound(string shipmentNumber) =>
        Error.NotFound($"{ErrorPrefix}.{nameof(NotFound)}",
            $"Shipment with number '{shipmentNumber}' not found");

    internal static Error AlreadyExists(string orderId) =>
        Error.Conflict($"{ErrorPrefix}.{nameof(AlreadyExists)}",
            $"Shipment for order '{orderId}' already exists");
}

Cross-module calls go through public APIs.
The handler does not reference any internals of the Stocks module.
It only uses IStockModuleApi, which is exposed by a separate Modules.Stocks.PublicApi project.

Events fire after the save.
Once the shipment is persisted, the handler publishes a ShipmentCreatedEvent.
Other slices and other modules can react to this event without the handler knowing about them.

The Mapping and Validation Concerns

I do all object mapping manually, in static extension methods (I don't use mapping libraries like AutoMapper, Mapster or Mapperly).

internal static class CreateShipmentMappingExtensions
{
    public static Shipment MapToShipment(this CreateShipmentRequest request)
    {
        // Mapping code omitted for brevity
    }

    public static ShipmentResponse MapToResponse(this Shipment shipment)
    {
        // Mapping code omitted for brevity
    }
}

Manual mapping has two big advantages:

It is explicit: you can navigate to it directly and know exactly what happens
It has no reflection overhead

If a mapping is reused across multiple slices, I move it into the Shared/ folder of the module instead of duplicating it.

For validation, I use FluentValidation.
I keep all validators for a slice in one file:

public class CreateShipmentRequestValidator : AbstractValidator<CreateShipmentRequest>
{
    public CreateShipmentRequestValidator()
    {
        RuleFor(shipment => shipment.OrderId).NotEmpty();
        RuleFor(shipment => shipment.Carrier).NotEmpty();
        RuleFor(shipment => shipment.ReceiverEmail).NotEmpty();
        RuleFor(shipment => shipment.Items).NotEmpty();

        RuleFor(shipment => shipment.Address)
            .Cascade(CascadeMode.Stop)
            .NotNull()
            .WithMessage("Address must not be null")
            .SetValidator(new AddressValidator());
    }
}

public class AddressValidator : AbstractValidator<Address>
{
    public AddressValidator()
    {
        RuleFor(address => address.Street).NotEmpty();
        RuleFor(address => address.City).NotEmpty();
        RuleFor(address => address.Zip).NotEmpty();
    }
}

The Shared Folder Within a Module

Some things are needed by more than one slice in the same module (of a Modular Monolith): route constants, errors and response shapes for related slices.
To avoid duplication, I put them in a Shared/ folder inside the module's Features project.

Features/
├── CreateShipment/
├── DispatchShipment/
├── GetShipmentByNumber/
└── Shared/
    ├── Errors/
    │   └── ShipmentErrors.cs
    ├── Requests/
    │   └── ShipmentItemRequest.cs
    ├── Responses/
    │   ├── ShipmentResponse.cs
    │   └── ShipmentItemResponse.cs
    └── Routes/
        └── RouteConsts.cs

For all the API endpoint names, I used a static class called RouteConsts:

internal static class RouteConsts
{
    internal const string BaseRoute = "/api/shipments";

    internal const string GetByNumber = $"{BaseRoute}/{{shipmentNumber}}";

    internal const string CancelShipment = $"{BaseRoute}/cancel/{{shipmentNumber}}";

    internal const string DispatchShipment = $"{BaseRoute}/dispatch/{{shipmentNumber}}";
    // ... and so on
}

I wrote a detailed guide on how to share code and avoid code duplication in Vertical Slices. Read it here.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-structure-production-apps-with-vertical-slice-architecture-in-dotnet-in-2026

40 Lessons I Learned in 12 Years as a .NET Developer

Anton Martyniuk — Fri, 16 Oct 2026 08:17:39 +0000

17 years ago, I wrote my first line of C# code (.NET Framework 3.5).
It was in the IT school.

12 years ago, I wrote my first application in .NET and pushed it to production.
It worked, but it had bad code. I did not know it at the time, but I would spend the next few years learning how to improve.

Over more than 12 years, I have shipped buggy releases.
I have over-engineered features nobody asked for.
I have argued about tabs and spaces in pull requests.

I have debugged distributed systems on weekends, missed estimates, and watched "future-proof" architectures rot into legacy.

Some lessons were painful.
Others were priceless.

None of them came from a textbook; they came from real projects, real bugs, and real teammates who pushed me to be better.

Today, I want to share the 40 most important takeaways I have learned over my career.
Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer

0. The best code is the one you don't write

Every line of code is a future liability.
It needs to be read, tested, debugged, deployed, and maintained for years.

The cheapest, safest, fastest code is the code that never gets shipped.

Before writing anything new, I ask myself: do we really need this? Is there a simpler way? Can an existing tool, library, or feature solve the problem instead?

Many projects fail because they have too much code.
Less code means fewer bugs, faster onboarding, and less time spent maintaining things nobody uses.

1. You're not paid to write code - you're paid to solve problems

Code is just a tool. The real product is the value you deliver to the business and to the users.

I have seen developers spend weeks polishing a feature nobody asked for, while a critical bug stayed in production.
I have seen teams build complex frameworks when a simple script that runs in 5 minutes would have done the job.

The best engineers I know start with the problem, not with the technology.
They ask questions, understand the context, and only then choose the right tool. And sometimes that tool is no code at all.

👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer

EF Core Optimization Guide: A Step-By-Step Guide to Faster Queries

Anton Martyniuk — Tue, 13 Oct 2026 11:07:50 +0000

"EF Core is slow, don't use it."

I heard this from so many developers.

And almost every time, the cause is the same: EF Core makes it very easy to write a query that loads far more data than you need, and then you blame it for speed.

Integration tests don't catch this.

In development, your queries complete in a few milliseconds for a database with a few hundred rows.
Then production grows to 2 million rows and the same endpoint takes 30 seconds.

I've spent a lot of time optimizing EF Core in production systems, and I know a set of techniques that work.

Some of them you need to apply daily, others - when you need to make it faster, or based on your specific datasets.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-optimization-guide-step-by-step

Step 0: Measure Before You Optimize

All examples in this article use a shipment tracking domain:

public class Shipment
{
    public Guid Id { get; set; }
    public string Number { get; set; }
    public string OrderId { get; set; }
    public string Carrier { get; set; }
    public string ReceiverEmail { get; set; }
    public ShipmentStatus Status { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? UpdatedAt { get; set; }

    public Address Address { get; set; }

    public List<ShipmentItem> Items { get; set; }
}

public class ShipmentItem
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }

    public Guid ShipmentId { get; set; }
    public Shipment Shipment { get; set; }
}

Note: all queries were tested on PostgreSQL. The same ideas apply to SQL Server, MySQL, and Oracle, though the generated SQL and the exact limits differ.

Most performance work goes wrong before a single line of code changes.

A query feels slow, someone puts a cache in front of it, and the endpoint gets faster.

The slow query is still there. It just runs less often, and it will hurt again the moment the cache misses or the data changes more frequently than you expected.

So the first step is finding out what SQL your LINQ actually produces.

Turn on query logging in development:

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

    if (builder.Environment.IsDevelopment())
    {
        options.LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging()
            .EnableDetailedErrors();
    }
});

LogTo writes every generated SQL statement to the console.
EnableSensitiveDataLogging includes the actual parameter values, so you can copy the statement straight into your database client and run it.

You can also enable EF Core logging through your logging configuration - set the Microsoft.EntityFrameworkCore.Database.Command category to Information and let your logging framework (Serilog, NLog) write the SQL to a file or a sink of your choice.

Note: never enable EnableSensitiveDataLogging in production. It writes parameter values, including emails, addresses, and anything else your queries filter on.

Once you have the SQL, run it with an execution plan (EXPLAIN ANALYZE in PostgreSQL, or the actual execution plan in SQL Server).
The plan tells you whether the database is scanning an entire table or using an index, and where the time is actually spent.

Let's explore the query plan for this small query (from the screenshot above) that finds a Shipment by a number:

var shipment = await context.Shipments
    .Include(x => x.Items)
    .Where(s => s.Number == shipmentNumber)
    .FirstOrDefaultAsync(cancellationToken);

Three numbers are worth checking every time:

Does the database use a full table scan or an index?
How many rows the database returns. If a query returns 50,000 rows to build a page of 100, the fix is in your LINQ in EF Core query.
How many round-trips your code makes. One request per loop iteration is a different problem from one slow request.

For anything you plan to tune repeatedly, write a benchmark with BenchmarkDotNet so you have a number to compare against.

Now that you can see what's actually happening, let's explore ways we can improve performance.

Fetch Less Data

Almost every slow EF Core query is slow for the same reason: it moves more data out of the database than the code needs.

The three optimizations in this step all attack that.

1. Add the Right Indexes

In EF Core (migrations), it automatically creates indexes for primary keys and foreign keys.
It doesn't create indexes for the columns you filter and sort on.

If your shipment list screen filters by status and orders by creation date, the database has to scan the table on every request:

Add the index in your entity configuration (the database migration will create it):

public class ShipmentConfiguration : IEntityTypeConfiguration<Shipment>
{
    public void Configure(EntityTypeBuilder<Shipment> builder)
    {
        builder.HasKey(x => x.Id);

        builder.HasIndex(x => x.Number)
            .IsUnique();

        builder.HasIndex(x => new { x.Status, x.CreatedAt });
    }
}

The composite index on (Status, CreatedAt) matches the shape of the query.

Column order matters here.
The database can use this index to filter by:

Status alone
Status and then sort by CreatedAt

But it can't use it to sort by CreatedAt alone.

Put the column you filter on for equality first, and the column you range-filter or sort on second.

When most of your queries only care about a small slice of the table, a filtered index is cheaper to maintain:

builder.HasIndex(x => x.CreatedAt)
    .HasFilter("\"Status\" NOT IN (4, 5)");

This indexes only the shipments that are still in flight and skips the delivered and canceled rows, which make up most of the table over time.

Remember that indexes aren't free.
Every index has to be updated on every insert, update, and delete that touches its columns.
Add indexes only for the query shapes you actually run.

Indexes help the database find your rows quickly. The next step is making sure you ask for fewer of them.

2. Filter Early, in the Database

This is the mistake I see most often from young developers (sometimes AI does this, duh!), and it usually hides behind a helper method:

// Loads every shipment in the table
var shipments = await dbContext.Shipments.ToListAsync(cancellationToken);

var pending = shipments
    .Where(s => s.Status == ShipmentStatus.Processing)
    .ToList();

The moment you call ToListAsync, the query is executed, and the rest happens in memory in your application.

The database sends every row over the network. EF Core materializes each row into an object. And then your code throws most of them away.

Keep the filter inside the IQueryable so it becomes a WHERE clause:

var pending = await dbContext.Shipments
    .Where(s => s.Status == ShipmentStatus.Processing
        && s.CreatedAt >= since)
    .ToListAsync(cancellationToken);

The same applies to sorting, grouping, and aggregation. Count(), Any(), Sum(), and Max() all translate to SQL when you call them on an IQueryable.
It all runs in memory when you call them after calling ToListAsync.

3. Project Only the Columns You Need

Loading a full entity means loading every column it maps to, including the ones your endpoint never returns.

If a Shipment has 10 columns and your list screen shows 4 of them, you're moving more than twice the data you need.

Project into a record or class instead:

public record ShipmentResponse(
    Guid Id,
    string Number,
    string Carrier,
    ShipmentStatus Status,
    DateTime CreatedAt);

var shipments = await dbContext.Shipments
    .Where(s => s.Status == ShipmentStatus.Processing)
    .OrderByDescending(s => s.CreatedAt)
    .Select(s => new ShipmentResponse(
        s.Id,
        s.Number,
        s.Carrier,
        s.Status,
        s.CreatedAt))
    .ToListAsync(cancellationToken);

EF Core translates the Select into a SELECT list with exactly those five columns.

Projections do three things at once:

They cut the size of data the database reads
They cut the size of data you transfer over the network from the database to your app
They skip change tracking entirely, because there's no entity to track.

This is consistently the single biggest win available.
Projecting only the required columns can take your query somewhat from 10 seconds to 40 milliseconds (when reading 10,000 or more rows).

You can explore the benchmarks in the optimization challenge I did before with EF Core.

Projections also compose well with aggregation:

var summaries = await dbContext.Shipments
    .Where(s => s.CreatedAt >= since)
    .Select(s => new ShipmentSummary(
        s.Number,
        s.Status,
        s.Items.Count,
        s.Items.Sum(i => i.Quantity)))
    .ToListAsync(cancellationToken);

The database computes the item count and quantity sum. No ShipmentItem objects are created in your application at all.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-optimization-guide-step-by-step

Building File-Based Apps in .NET: A Complete Guide With Multi-File Support

Anton Martyniuk — Fri, 09 Oct 2026 08:39:16 +0000

For years, even the smallest C# program required a solution file, a project file, and a folder structure.
While Python and JavaScript developers could create a single file and run it in seconds, .NET developers had to create a solution and add a csproj file just to test an idea.

That changed with .NET 10, which introduced file-based apps.
Now you can run a C# file directly with dotnet run.

And in April 2026 in .NET 11 Preview 3 we received a support for using multiple files in file-based apps with the #:include directive.

This finally makes C# a real option for scripts, automation, internal tooling, and quick prototypes - without the overhead of a full project.

In this post, we will explore:

What Are File-Based Apps in .NET
Adding NuGet Packages and SDKs with Directives
Splitting File-Based Apps Across Multiple Files
Building an HTTP Health-Check Tool
Building a Minimal API with EF Core and SQLite
Converting a File-Based App to a Full Project

Let's dive in!

👉 Read original article on my newsletter: https://antondevtips.com/blog/building-file-based-apps-in-dotnet-with-multi-file-support

What Are File-Based Apps in .NET

Traditionally, every C# application required three things:

Solution file (*.sln)
Project file (*.csproj)
Source code (*.cs).

Even for a 10-line script, you had to create a new solution, add a project with dotnet new console, wait for the scaffolding to finish, and only then write your actual code.

Starting with .NET 10, you can skip all of that.
You can create a single .cs file and run it directly:

dotnet run main.cs

That's it. No project file. No solution file. Just one file.

This puts C# on equal footing with Python, JavaScript, Node.js, and other scripting languages.
For CLI utilities, automation tasks, and one-off tools, this completely changes the workflow.

Let's see the simplest possible example. Create a file called hello.cs:

Console.WriteLine("Hello from a file-based app!");
Console.WriteLine($"Today is {DateTime.Now:dddd, MMMM d, yyyy}");

Then run it:

dotnet run hello.cs

Notice there is no Main method, no class Program, no using statement.
File-based apps build on top of top-level statements (introduced in C# 9) and implicit usings, so you can write code as if you were in a script.

Behind the scenes, the .NET CLI compiles your file in a temporary location and runs the resulting binary.
The first run takes a moment, but subsequent runs are cached and fast.

I've used this many times in the last year for small tasks I would have otherwise written in Python (or created a solution project):

Quick data transformations on JSON or CSV files
Calling internal APIs to verify a deployment
Running test scripts
Parsing log files to extract patterns

Adding NuGet Packages and SDKs with Directives

A real script usually needs more than the BCL.
You probably want JSON parsing, HTTP calls, or database access.

File-based apps support special # directives at the top of your file to declare dependencies.

The #:package Directive

Use #:package to reference any NuGet package:

#:package Newtonsoft.Json@13.0.3

using Newtonsoft.Json;

var data = new { Name = "Anton", Year = 2026 };
var json = JsonConvert.SerializeObject(data, Formatting.Indented);
Console.WriteLine(json);

The format is #:package PackageName@Version.
The .NET CLI restores the package on first run, just like it would for a regular project.

The #:sdk Directive

Use #:sdk when you need a specific SDK, such as the Web SDK for ASP.NET Core:

#:sdk Microsoft.NET.Sdk.Web

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

app.MapGet("/", () => "Hello from a single-file API!");

app.Run();

By default, file-based apps use Microsoft.NET.Sdk (the standard SDK).
Switching to Microsoft.NET.Sdk.Web unlocks ASP.NET Core types like WebApplication without any project setup.

The #:project Directive

If you need to call into an existing project (for example, a shared class library), use #:project:

#:project ../MyLibrary/MyLibrary.csproj

using MyLibrary;

var calculator = new Calculator();
Console.WriteLine(calculator.Add(2, 3));

This is helpful when you have a class library and want to write a quick tool that uses it, without creating yet another console project.

👉 Read original article on my newsletter: https://antondevtips.com/blog/building-file-based-apps-in-dotnet-with-multi-file-support

How to Make AI Write High-Quality Code in .NET

Anton Martyniuk — Tue, 06 Oct 2026 11:10:00 +0000

AI writes .NET code faster than anyone on your team.

It can also write code that looks good but can fall apart during careful review.

I have spent years improving the quality of code I write, long before the AI was around.
I learned to write code that is easy to read and maintain, and I have been refining my skills ever since.

Now I'm doing the same by teaching AI agents to write code with the same quality I do.

But most developers fail to get AI to write high-quality, clean code.
The reason is simple. The AI followed the rules it could see, and it never saw yours.

Most developers try to fix this by putting the rules in the prompt.
I tried that for many months.

The rules work for a few files, maybe a few iterations in a session.
But as the session goes on, the context gets loaded with information, and your rules start to be ignored.

So only two things actually work reliably that I want to show you today:

Static compiler guardrails. If bad code doesn't compile, the agent sees the error, fixes it, and you never review that mistake at all.
A skill for reviewing code. It's being used in another session, so it never competes with the original task.

In this post, we will explore:

Set Project-Wide Standards with Directory.Build.props
Add Static Code Analysis Packages
Enforce Coding Standards with .editorconfig
Centralize Package Management
Code Reviews: AI First, Human Second
Why Coding Rules in Prompts Don't Work
Build a Clean Code Review Skill for Claude
Make Sure the Review Catches Every Issue

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-make-ai-write-high-quality-code-in-dotnet

1. Set Project-Wide Standards with Directory.Build.props

Every .NET solution should start with a Directory.Build.props file. This file defines project-wide settings that apply to all projects in your solution.

Without this file, you end up duplicating the same configuration across multiple .csproj files.
When you want to change a setting, you have to update every project file by hand. This leads to inconsistencies and wasted time.

Directory.Build.props solves this problem by centralizing configuration in a single file.
You create this file in the same directory as your .sln file, and MSBuild applies it to all projects in the solution.

Here is the configuration I use for every new project:

<Project>
    <PropertyGroup>
        <Nullable>enable</Nullable>
        <ImplicitUsings>enable</ImplicitUsings>
        <AnalysisLevel>latest</AnalysisLevel>
        <AnalysisMode>All</AnalysisMode>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
        <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
        <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    </PropertyGroup>
</Project>

Here is what each setting does:

Nullable: Enables nullable reference types, which help prevent null reference exceptions. The compiler warns you when you might be using a null value incorrectly.

ImplicitUsings: Adds common namespace imports to every file. You don't need to write using System; or using System.Linq; anymore.

AnalysisLevel: Sets the code analysis level to the latest version. You get the most recent code quality checks from Microsoft.

AnalysisMode: Turns on all code analysis rules. This gives you the most feedback on code quality.

TreatWarningsAsErrors: Stops compilation if there are any warnings. This forces you to fix issues right away instead of letting them pile up.

CodeAnalysisTreatWarningsAsErrors: Applies the same strict treatment to code analysis warnings.

EnforceCodeStyleInBuild: Runs code style checks during build, not just in the IDE. Your CI/CD pipeline will catch style violations.

Now here is why this file matters more than ever.

An AI agent doesn't read your standards. It runs dotnet build, and it reads the output.

TreatWarningsAsErrors turns every analyzer rule into a build error. The agent detects the error, fixes it, and rebuilds. That loop runs before you ever open the diff.

Without this one line, the same rules become warnings. Warnings can get ignored by agents.

That is the pattern behind everything below. A rule the build enforces gets followed every time, and a rule that only lives in a document gets skipped as soon as the agent has busy context.

2. Add Static Code Analysis Packages

Code quality is something you need to care about from day 1.
It's easier to follow the best coding practices than to fix them later.

For this, we can use static code analysis.

Static code analyzers examine your code without running it.
They catch common mistakes, enforce coding standards, and find potential bugs before they reach production.

Some of the analyzers can even catch code quality issues.
They can detect:

Too long or too complex methods
Methods with too many parameters
Too much nesting
Unused code

The analyzers run during compilation, so you get feedback right away in your IDE and in your CI/CD pipeline.

Add these analyzer packages to your Directory.Build.props file:

<Project>
    <PropertyGroup>
        <Nullable>enable</Nullable>
        <ImplicitUsings>enable</ImplicitUsings>
        <AnalysisLevel>latest</AnalysisLevel>
        <AnalysisMode>All</AnalysisMode>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
        <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
        <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Meziantou.Analyzer" Version="2.0.257">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>
        <PackageReference Include="SonarAnalyzer.CSharp" Version="10.16.0.128591">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>
        <PackageReference Include="Roslynator.Analyzers" Version="4.14.1">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>
        <PackageReference Include="xunit.analyzers" Version="1.26.0">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>
    </ItemGroup>
</Project>

Here is what each analyzer provides:

SonarAnalyzer.CSharp: Focuses on code quality, security holes, and code smells. It finds complex methods, duplicated code, and potential bugs.

Meziantou.Analyzer: Catches performance issues, security holes, and incorrect API usage. It has hundreds of rules covering async/await patterns, LINQ usage, string handling, and more.

Roslynator.Analyzers: Provides code analysis and refactoring suggestions. It helps you write cleaner, more idiomatic C# code.

xunit.analyzers: Makes sure you write tests correctly. It catches common testing mistakes, such as missing assertions or wrong test attributes.

The IncludeAssets configuration makes sure that these analyzers run during compilation but don't get included in your published application.

With TreatWarningsAsErrors enabled, your build will fail if any analyzer finds an issue. This might seem strict, but it stops technical debt from piling up.

You should always aim for zero warnings in your project. Many developers ignore warnings, but warnings often point at real problems that will cause bugs later.

These four packages carry thousands of rules between them. That's thousands of rules an AI agent has to satisfy, and none of them cost you a single line in a prompt.

For more information about code quality best practices, check out this article.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-make-ai-write-high-quality-code-in-dotnet

Getting Started With Dapr for Building Cloud-Native Microservices in .NET

Anton Martyniuk — Sat, 03 Oct 2026 07:00:06 +0000

Building microservices is hard.

Microservices don't just come with scalability, they come with mandatory complexity you pay for upfront and forever.

You need to handle service-to-service communication, message brokers, state management, secrets, and more.
Each of these concerns requires its own library, configuration, and expertise.

What if there were a runtime that provided all these capabilities out of the box, regardless of the infrastructure you use?

That is exactly what Dapr does.

Dapr (Distributed Application Runtime) is a portable, event-driven runtime that makes it easier to build resilient microservices.
It provides a set of building block APIs for common distributed systems challenges: pub/sub messaging, service invocation, state management, secrets, and more.

The best part? Dapr is infrastructure-agnostic.
You can swap RabbitMQ for Kafka, or Redis for PostgreSQL, without changing a single line of application code.

Dapr is a free and open-source project; you can see its GitHub repo here.

And when you combine Dapr with .NET Aspire, you get a powerful local development experience where containers, sidecars, and services are orchestrated for you with a single command.

In this post, we will explore:

What is Dapr and How It Simplifies Microservice Development?
Understanding Dapr Building Blocks
How Dapr Components Work
How to set up Dapr with .NET Aspire
How to use Dapr to Publish Events to a Message Queue with Pub/Sub
How to use Dapr to Consume Events from a Message Queue
How to use Dapr to Call REST Services with Service Invocation
How to use Dapr to Manage State with State Management

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-dapr-for-building-cloud-native-microservices-in-dotnet

What is Dapr and How It Simplifies Microservice Development?

When you build microservices, you quickly face a set of recurring challenges:

How do services discover and call each other reliably?
How do you publish and consume events across services?
How do you store state without coupling to a specific database?
How do you manage secrets securely?
How do you handle retries, timeouts, and circuit breakers?

Without Dapr, you solve each problem independently.
You install a RabbitMQ client library for messaging, a Redis library for caching, a Vault client for secrets, and write custom retry logic.
Each library has its own API, configuration, and behavior.

You can use messaging libraries such as MassTransit, Wolverine, Rebus or Brighter, but they solve only the async messaging flows.
You still need to implement caching, secrets, synchronous communication, service discovery, and others.

Dapr solves all of these by providing a unified set of APIs that abstract these concerns.
Your application talks to Dapr, and Dapr talks to the infrastructure.

If you need to switch from RabbitMQ to Kafka for messaging, you change a configuration file (in production).
Your application code stays exactly the same.

How the Sidecar Architecture Works

Dapr runs as a sidecar alongside your application.
This means Dapr is a separate process (or container) that runs next to your service.

Your application communicates with the Dapr sidecar over HTTP or gRPC on localhost.
The sidecar handles the actual interaction with external infrastructure: message brokers, databases, secret stores, and other services.

Here is how it works:

In a Kubernetes environment, Dapr runs as a companion container within the same pod as your application.
In local development, it runs as a separate process on your machine.

This sidecar architecture provides several benefits:

Language agnostic: Dapr works with any language that can make HTTP or gRPC calls. Whether you write in C#, Go, Python, or Java, you use the same Dapr APIs.
No SDK lock-in: While Dapr provides SDKs for popular languages (including .NET), you can always fall back to raw HTTP calls.
Independent lifecycle: Your application and the Dapr sidecar can be updated independently. Upgrading Dapr does not require recompiling your application.
Consistent behavior: Retry policies, timeouts, and circuit breakers are configured at the sidecar level. Every service in your system automatically receives the same resilience guarantees.

Each service in your system has its own Dapr sidecar.
When Service A wants to call Service B, it tells its local Dapr sidecar.
The sidecar handles service discovery, routes the request to Service B's sidecar, which then forwards it to Service B.

This means your services never communicate directly with each other.
All communication goes through the Dapr sidecars, which gives you observability, security, and resilience for free.

What about an overhead when talking to the sidecar on each request?
This overhead is minimal, as all requests are done on the localhost.

And the benefits you get outpass this small disadvantage.

Understanding Dapr Building Blocks

Dapr organizes its capabilities into building blocks.
Each building block is an independent API that addresses a specific challenge in distributed systems.

You can use any combination of building blocks.

Here are the main building blocks:

Service Invocation

Enables services to call each other reliably.
Dapr handles service discovery, retries, and distributed tracing automatically.

Instead of hardcoding URLs or using a service registry, you reference services by their App ID:

// Call the "hotels-api" service via Dapr
var rooms = await daprClient.InvokeMethodAsync<RoomAvailabilityResponse>(
    HttpMethod.Get,
    "hotels-api",
    "hotels/1/rooms/available");

Dapr resolves the address of hotels-api service, routes the request through the sidecar network, and returns the response.
If the target service is temporarily unavailable, Dapr can retry the request based on your configured policies.

Publish and Subscribe

Allows services to communicate asynchronously through queues and topics.
Publishers send events to a topic, and subscribers receive them.

The pub/sub building block supports at-least-once delivery guarantees.
It works with any supported message broker: RabbitMQ, Kafka, Azure Service Bus, Redis Streams, and more.

await daprClient.PublishEventAsync("pubsub", "booking-created", bookingEvent);

Subscribers receive events through HTTP endpoints that Dapr calls automatically:

app.MapPost("/dapr/booking-created",
    [Topic("pubsub", "booking-created")]
    async (BookingCreatedEvent message) =>
    {
        // Process the event
        return Results.Ok();
    });

This model is fundamentally different from traditional background service consumers.
Dapper Sidecar subscribes to a message queue, receives your message and pushes it to your application via HTTP POST requests.

State Management

Provides key/value state storage with pluggable backends.
You can use Redis, PostgreSQL, MongoDB, Azure Cosmos DB, or any other supported state store.

// Save state
await daprClient.SaveStateAsync("statestore", "user-123", userData);

// Get state
var user = await daprClient.GetStateAsync<UserData>("statestore", "user-123");

// Delete state
await daprClient.DeleteStateAsync("statestore", "user-123");

The state management building block also supports:

Concurrency control with ETags for optimistic locking
TTL (Time-to-Live) for automatic expiration
Transactions for atomic operations across multiple keys

Secrets Management

Retrieves secrets from various secret stores without hardcoding credentials in your application.
Supported stores include Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, Kubernetes secrets, and local file-based stores.

var secrets = await daprClient.GetSecretAsync("secretstore", "payment-gateway");
var apiKey = secrets["api-key"];

Bindings

Creates connections to external systems.
Input bindings trigger your application when an external event occurs.
Output bindings let your application invoke external systems.

For example, you can use an output binding to write files to local storage, send emails, or trigger a cloud function:

await daprClient.InvokeBindingAsync("email-output", "create", emailContent);

Distributed Lock

Provides mutual exclusion for scenarios where multiple service instances might access the same resource concurrently:

var lockResponse = await daprClient.Lock(
    "statestore", "room-lock:101", "owner-id", expiryInSeconds: 30);

if (lockResponse.Success)
{
    // Exclusive access to the resource
    await daprClient.Unlock("statestore", "room-lock:101", "owner-id");
}

Other Building Blocks

Dapr also provides building blocks for:

Workflows: Long-running, persistent processes that span multiple services
Actors: Virtual actor model for stateful computations with single-threaded execution
Configuration: Dynamic application configuration retrieval and subscription
Cryptography: Encryption and decryption operations
Jobs: Scheduled and triggered batch processing

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-dapr-for-building-cloud-native-microservices-in-dotnet

How to Build Production-Ready Projects With Claude Code

Anton Martyniuk — Fri, 02 Oct 2026 08:17:01 +0000

In modern software development, there are two common paths:

You don't use AI, and you spend weeks on architecture decisions and months writing boilerplate code.
You use AI heavily, shortcut every possible architecture decision, vibe-code 98% of your project, and ship quickly with low quality.

Neither of these paths is great.

I want to tell you something about AI-assisted development in 2026.

If you don't understand your programming language deeply, your main web framework, HTTP, databases, concurrency fundamentals, Architecture Patterns, tradeoffs...
You can't tell when the code generated by Claude or Copilot is subtly wrong - and it will be, often enough to matter in production.

AI amplifies what you already know.

The stronger your fundamentals, the better your judgment on what Architecture Decisions to make, what to keep, what to fix, and what to throw away entirely.
And going forward, developers with deep knowledge who operate AI, will be the most valued.

Over the past year, I built a 10-step workflow that I use to ship quality software much quicker with AI.
This workflow is designed to create well-architected, production-ready software with solid architecture, proper validation, error handling, security, and clean code.

You should treat AI as your personal assistant who helps you in each phase of design and development.
You guide it through a structured process where each step builds on the output of the previous one.

In this post, I will share the complete workflow with detailed prompts you can adapt for your own projects.

In this post, we will explore:

Why most AI-generated code fails in production
The 10-step workflow I use to ship production-quality software with AI
Prompt engineering principles for production code

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-build-production-ready-projects-with-claude-code

Why Most AI-Generated Code Fails in Production

The most common way developers use AI for coding is what I call "vibe coding."
You open a chat, type "build me a REST API for managing orders," and get back something that compiles.

The generated code typically has:

Poor code quality
Poor input validation (or just inline if-else statements)
No error handling strategy (or try-catch in API endpoints)
No consistent project structure
No separation of concerns
Hard-coded configuration
No logging or observability
No security considerations
No tests

This happens because the AI has no context about your project.
It does not know your architecture decisions, your team's coding conventions, your error handling patterns, or your deployment constraints.
It gives you a generic answer to a generic question.

And even with the best AI models, like Claude Opus, with such generic prompts, you cannot guarantee that the output will be production-ready.

Production-ready code means something specific:

It follows a consistent architecture across the entire codebase
It has high-quality code
It handles errors gracefully with a unified error response format
It validates all user inputs
It uses proper logging and has observability
It follows your team's naming conventions and file organization
It is structured for testing and maintenance
It has a comprehensive test suite

To achieve this, we need a better process.
When you give AI structured requirements, architecture decisions, and code examples to follow, the output quality increases dramatically.

The workflow I share in this post mirrors how experienced developers already think:

Requirements
Architecture
Specification
Writing code
Reviewing code
Testing code and deploying

AI accelerates each step, but the human remains the architect and decision-maker.
I always said that the creative and decision-making part should always be on us, humans.

The 10-Step Workflow to Ship Production-Quality Software with AI

I have created and refined this workflow over time to ship production-quality software with AI.

The workflow has 5 phases and 10 steps:

Phase 1: Requirements and Planning

Step 1: Define Business Requirements
Step 2: Define Non-Functional Requirements

Phase 2: Architecture and Specification

Step 3: Design the Architecture
Step 4: Generate the Backend Specification

Phase 3: Backend Implementation

Step 5: Code the Backend
Step 6: Review and Refine

Phase 4: Frontend Implementation

Step 7: Generate the Frontend Specification
Step 8: Code the Frontend

Phase 5: Deployment

Step 9: Automate Deployment with CI/CD
Step 10: Human Review, Test, and Deploy

Each phase produces artifacts that feed into the next phase.

Let's walk through each step in detail.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-build-production-ready-projects-with-claude-code

The Real Cost of Returning the Identity Value in EF Core

Anton Martyniuk — Wed, 30 Sep 2026 12:39:09 +0000

When you insert thousands of rows into SQL Server with Entity Framework Core, performance drops quickly.

Most developers blame change tracking.
But there is another hidden cost that slows down every SaveChanges call: returning database-generated identity values back to your entities.

If your table has an auto-increment primary key (like most SQL Server tables), EF Core must ask the database for each generated identity after the insert.
This round-trip limits batch size, forces extra SQL logic, and is the reason SaveChanges struggles at scale.

In this post, you will learn:

Why SaveChanges is slow when inserting 10,000 rows into a table with an identity column
How EF Core handles generated value properties under the hood
How Entity Framework Extensions solves this problem with BulkInsert
How to make BulkInsert faster with the AutoMapOutputDirection option
Why BulkInsertOptimized is the fastest bulk insert method and how it compares with the other approaches
When you should (and shouldn't) return identity values after a bulk insert

All examples in this post were tested against a SQL Server database running in Docker, with benchmarks written in BenchmarkDotNet on .NET 10.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/the-real-cost-of-returning-the-identity-value-in-ef-core

The Problem: Inserting 10,000 Rows with EF Core SaveChanges

I built a small benchmark project to measure how long EF Core takes to insert 10,000 Product rows into SQL Server.

Here is the Product entity:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public string Description { get; set; } = string.Empty;
    public string Sku { get; set; } = string.Empty;
    public string Barcode { get; set; } = string.Empty;
    public string Category { get; set; } = string.Empty;
    public string Brand { get; set; } = string.Empty;
    public string Manufacturer { get; set; } = string.Empty;
    public int StockQuantity { get; set; }
    public decimal Weight { get; set; }
    public bool IsActive { get; set; } = true;
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime? UpdatedAt { get; set; }
}

And the Fluent API mapping that configures the identity column:

public class ProductConfiguration : IEntityTypeConfiguration<Product>
{
    public void Configure(EntityTypeBuilder<Product> builder)
    {
        builder.HasKey(p => p.Id);

        builder.Property(p => p.Id).ValueGeneratedOnAdd();

        builder.Property(p => p.Name).IsRequired().HasMaxLength(250);
        builder.Property(p => p.Price).IsRequired().HasColumnType("decimal(18,2)");
        builder.Property(p => p.Description).HasMaxLength(1000);

        builder.Property(p => p.Sku).IsRequired().HasMaxLength(50);
        builder.Property(p => p.Barcode).IsRequired().HasMaxLength(20);
        builder.Property(p => p.Category).IsRequired().HasMaxLength(100);
        builder.Property(p => p.Brand).IsRequired().HasMaxLength(100);
        builder.Property(p => p.Manufacturer).IsRequired().HasMaxLength(100);
        builder.Property(p => p.StockQuantity).IsRequired();
        builder.Property(p => p.Weight).IsRequired().HasColumnType("decimal(10,3)");
        builder.Property(p => p.IsActive).IsRequired().HasDefaultValue(true);
        builder.Property(p => p.CreatedAt).IsRequired();
        builder.Property(p => p.UpdatedAt);

        builder.HasIndex(p => p.Sku).IsUnique();
    }
}

The ValueGeneratedOnAdd() call tells EF Core that the database will generate Id on insert.
On SQL Server, this maps to an IDENTITY(1,1) column.

Here is the baseline benchmark that uses the standard SaveChangesAsync approach:

[Benchmark]
public async Task SaveChangesAsync()
{
    var products = GenerateProducts(10_000);
    _dbContext.Products.AddRange(products);
    await _dbContext.SaveChangesAsync();
}

I use Bogus to generate fake products:

public static List<Product> GenerateProducts(int count)
{
    return new Faker<Product>()
        .RuleFor(p => p.Name, f => f.Commerce.ProductName())
        .RuleFor(p => p.Description, f => f.Lorem.Paragraph())
        .RuleFor(p => p.Price, f => decimal.Parse(f.Commerce.Price()))
        .RuleFor(p => p.Sku, f => $"SKU-{Guid.NewGuid():N}")
        .RuleFor(p => p.Barcode, f => f.Commerce.Ean8())
        .RuleFor(p => p.Category, f => f.Commerce.Categories(1)[0])
        .RuleFor(p => p.Brand, f => f.Company.CompanyName())
        .RuleFor(p => p.Manufacturer, f => f.Company.CompanyName())
        .RuleFor(p => p.StockQuantity, f => f.Random.Int(0, 10_000))
        .RuleFor(p => p.Weight, f => Math.Round(f.Random.Decimal(0.01m, 50m), 3))
        .RuleFor(p => p.IsActive, f => f.Random.Bool(0.9f))
        .RuleFor(p => p.CreatedAt, f => f.Date.Past(2).ToUniversalTime())
        .RuleFor(p => p.UpdatedAt, f => f.Date.Recent(30).OrNull(f, 0.3f)?.ToUniversalTime())
        .Generate(count);
}

On my SQL Server instance running in Docker, this benchmark takes around 7,000 ms for 10,000 rows.
For production APIs with a strict p99 SLA, that is way too slow.

But here is the interesting part: the slowdown is not only change tracking.
A large part of the cost comes from EF Core's need to return the database-generated Id back to every entity.

Let's see why.

Why EF Core Is Slow When Returning Identity Values

When Product.Id is marked as ValueGeneratedOnAdd, EF Core must perform two jobs during SaveChanges:

Insert the row into the database
Retrieve the generated identity value and assign it back to the in-memory Product.Id

On SQL Server, EF Core uses a MERGE statement with an OUTPUT clause to batch multiple inserts into one command and still return each new identity.

The generated SQL looks roughly like this:

MERGE [products].[products] USING (
    VALUES (@p0, @p1, @p2),
    (@p3, @p4, @p5),
    (@p6, @p7, @p8)
    ) AS i ([name], [price], [description])
    ON 1 = 0
    WHEN NOT MATCHED THEN
    INSERT ([name], [price], [description]) VALUES (i.[name], i.[price], i.[description])
    OUTPUT INSERTED.[id];

This approach is clever, but it has hard limits:

The 2,100 parameter cap - SQL Server allows a maximum of 2,100 parameters per command. With 14 mapped columns, that is roughly 100-200 rows per batch. For 10,000 Product rows, EF Core needs many round-trips.
Parameter binding cost - Every parameter has to be created, bound, and sent over the network. For 10,000 rows with a few columns, that is tens of thousands of parameters.
Change tracker overhead - After each batch, EF Core updates the change tracker and assigns the returned identity values to each tracked entity.
Log writes and index updates - The database writes to the transaction log and updates indexes for every batch.

You might think: "What if I disable the identity column?"
That removes the OUTPUT round-trip, but now you are responsible for generating unique IDs, and you lose the simplicity of auto-increment keys.

For a deeper explanation of how EF Core handles generated values, see this article on LearnEntityFrameworkCore.

There is a better solution.

👉 Read original article on my newsletter: https://antondevtips.com/blog/the-real-cost-of-returning-the-identity-value-in-ef-core

How to Model Relationships in NoSQL Databases

Anton Martyniuk — Tue, 29 Sep 2026 11:12:58 +0000

After you move from a SQL database to NoSQL, you usually forget about:

Joins
Foreign keys
Normalization and Denormalization
Database migrations

Yet, most developers have no idea how to model relationships in NoSQL correctly.

Most developers come to MongoDB (for example) after years of SQL.
So they model the data the way SQL taught them.

Customers, Orders and Order Items - all go in multiple collections by habit.
Every link becomes an ID, just like a foreign key.

Then they write the joins by hand in C#, because MongoDB has no JOIN keyword.

The result is a document database that behaves like a slow relational one.
A single read needs four database round trips.

I've run MongoDB in production for years.
Almost every performance problem I've seen there came from the wrong data model.

Today you will learn how to model relationships in a document database.

In this post, we will explore:

Why Relationships Work Differently in NoSQL
Embed or Reference: The Core Decision
One-to-One: Embed by Default
One-to-Many: The Three Sizes
- One-to-Few: Embed the Array
- One-to-Many: Reference from the Child
- One-to-Zillions: Never Grow an Array Forever
Many-to-Many: Orders and Products
Reading Related Data Without Joins
Keeping Duplicated Data Correct
4 Mistakes That Break NoSQL Data Models
The Same Rules in DynamoDB, Cassandra and Cosmos DB

All the code in this article I show using MongoDB and C#, but the rules apply to any NoSQL database.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-model-relationships-in-nosql-databases

Why Relationships Work Differently in NoSQL

In SQL databases, you have tables and rows.
In NoSQL databases, you have collections and documents.

A document is one record. It's a JSON-like object that can contain other objects and arrays.

A collection is a group of documents. It's the closest thing MongoDB has to a table.

MongoDB has no foreign key constraints. Nothing stops you from deleting a customer who still has orders.

There are no cascade deletes either. Delete a parent, and the children stay behind as orphans.

And a normal query can't join. MongoDB can join inside the aggregation pipeline, but that isn't how you read data most of the time.

In SQL you design the tables first and write the queries later. You normalize the data, which means you store each fact once and link to it.
The query planner works out the rest.

In a document database, you do the opposite. You shape the documents around the queries you already know you need.

Here's the same shipment in both worlds. In SQL it's three tables:

shipments         (id, number, order_id, status)
shipment_address  (shipment_id, street, city, zip)
shipment_items    (id, shipment_id, product, quantity)

Reading one shipment means joining all three.

In MongoDB, it's one document:

{
  "_id": "8e3b1a6c-2f45-4d17-9b0a-51c9e2f7a410",
  "number": "12345678",
  "orderId": "ORD-9931",
  "status": "Dispatched",
  "address": { "street": "Main St 15", "city": "Warsaw", "zip": "00-001" },
  "items": [
    { "product": "Laptop", "quantity": 1 },
    { "product": "Mouse", "quantity": 2 }
  ]
}

One read returns the whole shipment, without joins.

Side by side, the two shapes look like this:

SQL: 3 tables                                 MongoDB: 1 document
-------------------------------------------   ---------------------------------
shipments        (id, number, status)         shipment { number, status,
shipment_address (shipment_id, street,          address: { street, city, zip },
                  city, zip)                    items: [ { product, quantity } ]
shipment_items   (id, shipment_id,            }
                  product, quantity)

Embed or Reference: The Core Decision

In a NoSQL database, you have just two tools.

Embed means you put the related data inside the parent document. The address above is embedded in the shipment.

Reference means you store an id and keep the data in its own collection. That's the same idea as a foreign key, except the database doesn't enforce it.

Every relationship in your model is one of those two. Picking the right one is most of the work.

Here's the rule I use:

Embed when	Reference when
You read both together almost every time	The child is often read on its own
The list has a known upper limit	The list can grow infinitely
The child changes when the parent changes	The child is updated on its own schedule
The child belongs to one parent	Many parents share the same child
The data is small	The data is large

One hard limit settles a lot of arguments. A MongoDB document can't be bigger than 16 MB.
If a list can outgrow that, it can't be embedded, and there's nothing left to discuss.

Speed pushes the other way. Embedded data comes back in the same read, so it costs nothing extra to fetch.

Note: A good model embeds some things and references others. Don't pick one style and apply it everywhere.

Now I will show you the three shapes a relationship can take.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-model-relationships-in-nosql-databases

How to Add JWT Authentication to SignalR Hubs in ASP.NET Core

Anton Martyniuk — Fri, 25 Sep 2026 08:11:41 +0000

SignalR makes real-time communication in .NET applications simple.
You can send live data, notifications, and streaming updates to clients with minimal code.

By default, SignalR hubs are accessible to all clients.
Clients can connect, call hub methods, and receive messages without authentication.

In production, you may need to know who is connecting to your hub, what they are allowed to do, and how to reject unauthorized access.

JWT authentication is the standard for securing SignalR hubs in any environment, including browsers.
It works with WebSockets, Server-Sent Events, and Long Polling transports.

In this post, we will explore:

Why SignalR Needs Authentication
Setting Up JWT Authentication for SignalR
How to Stream Events with SignalR for a Given User
Role-Based Authorization on Hub Methods
Connecting from a JavaScript Client
Connecting from a .NET Client
Security Best Practices for SignalR

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-add-jwt-authentication-to-signalr-hubs-in-aspnetcore

Why SignalR Needs Authentication

SignalR uses multiple transport protocols to maintain real-time connections: WebSockets, Server-Sent Events, and Long Polling.

By default, any client can connect to a SignalR hub and call its methods.

This creates several problems in production:

No user identity - You can't tell who is connected or send messages to specific users.
No access control - Anyone can call any hub method, including admin operations.
No audit trail - You can't log which users performed which actions.
Security exposure - Sensitive data could be streamed to unauthorized clients.

Why JWT and not Cookies?

Cookies work well for browser-based apps where users log in through a web form.

But JWT tokens are the better choice when:

Your clients are mobile apps, desktop apps, or SPAs.
You need cross-platform authentication.
Your API and frontend run on different domains.
You're building microservices that need stateless authentication.

There is one important detail about how tokens are handled in SignalR connections.
In standard REST APIs, the client sends the JWT token in the Authorization HTTP header.
But SignalR can't always do this.

When using WebSockets or Server-Sent Events in a browser, the browser API does not allow setting custom headers.
Instead, the token is sent as a query string parameter: ?access_token=<token>.

This means you need extra configuration on the server to read the token from the query string.
We will cover this setup in the next section.

For a deeper dive into authentication and authorization in ASP.NET Core, read my article on Authentication and Authorization Best Practices.

Setting Up JWT Authentication for SignalR

Let's build the backend for the stock price streaming application.

In Modern .NET versions, you no longer need to install the SignalR NuGet package.
SignalR is now included in the ASP.NET Core Web SDK.

Here is how you can configure SignalR in your project:

builder.Services.AddSignalR();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// Map the SignalR hub
app.MapHub<StockPriceHub>("/hubs/stocks");

We need to configure JWT bearer authentication and add the OnMessageReceived event handler that extracts the token from the query string for SignalR connections:

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(authConfig.Key));

    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = authConfig.Issuer,
        ValidAudience = authConfig.Audience,
        IssuerSigningKey = key
    };

    options.Events = new JwtBearerEvents
    {
        OnMessageReceived = context =>
        {
            var accessToken = context.Request.Query["access_token"];

            var path = context.HttpContext.Request.Path;

            if (!string.IsNullOrEmpty(accessToken) &&
                path.StartsWithSegments("/hubs"))
            {
                context.Token = accessToken;
            }

            return Task.CompletedTask;
        }
    };
});

When a browser connects to a SignalR hub via WebSockets or SSE, it can't send the Authorization header.
The JavaScript client sends the token as ?access_token=<token>.

The OnMessageReceived event fires before the JWT middleware validates the token.

Token extraction is limited to paths starting with /hubs.
This avoids reading tokens from query strings on other endpoints.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-add-jwt-authentication-to-signalr-hubs-in-aspnetcore

Getting Started With Event Sourcing in .NET With Marten and PostgreSQL

Anton Martyniuk — Fri, 25 Sep 2026 04:42:41 +0000

Most applications store data by saving the current state to a database.

When a customer adds an item to a shopping cart, you update a row in the database.
The previous state is lost.
You only see the cart's current state, with all history lost.

This works for many applications. But what happens when you need to know the full history of changes?
What if you need to rebuild past states, debug complex business flows, or generate analytics from historical data?

This is where the Event Sourcing pattern is useful.

Event Sourcing stores every change as an immutable event.
Instead of overwriting data, you append new events to a stream.
The current state is derived by replaying these events.

In this post, I will show you how to build an Event Sourcing application in .NET using the Marten library and PostgreSQL.

We will build a Shopping Cart that demonstrates all the core Event Sourcing concepts: events, streams, aggregates, commands, and projections.

In this post, we will explore:

What is Event Sourcing
Overview of the Shopping Cart Application
Setting Up Marten with PostgreSQL
Defining Domain Events
Building the Aggregate
Writing Commands: Appending Events to Streams
Building Read Models with Projections
The Query Side: Reading Projected Data
When to Use Event Sourcing
Summary

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-event-sourcing-in-dotnet-with-marten-and-postgresql

What is Event Sourcing

In traditional CRUD applications, you store the current state of an entity in a database row.

When a customer adds a product to a shopping cart, you insert or update a row in the CartItems table.
When they remove an item, you delete that row.
The database always shows the latest state.

This approach is simple and works well for many use cases. But it has a fundamental limitation: you lose history.

If a customer added 5 items, removed 2, changed quantities 3 times, and then checked out, all you see in the database is the final state.
You cannot answer questions like "What did the cart look like 10 minutes ago?" or "Which items were removed before checkout?"

Event Sourcing takes a different approach. Instead of storing the current state, you store the sequence of events that led to the current state.

For a shopping cart, these events might look like:

CartCreated - Customer started a new cart
ItemAdded - Wireless Mouse, quantity 1
ItemAdded - Mechanical Keyboard, quantity 1
ItemRemoved - Wireless Mouse
ItemAdded - Gaming Mouse, quantity 2
CartCheckedOut - Customer completed the purchase

The current state of the cart is derived by replaying all these events from the beginning. This sequence of events is called an event stream.

Core Concepts

Event Sourcing introduces several core concepts that work together:

Events are immutable facts that describe something that happened in the past.
An event is never deleted or modified.
Once ItemAdded is recorded, it stays in the stream forever.
Events use past tense names: CartCreated, ItemAdded, OrderConfirmed.

Streams are ordered sequences of events that belong to the same entity.
A shopping cart has its own stream. Each stream has a unique identifier, typically a GUID.
All events for cart abc-123 are stored together in correct order as they appear in time.

Aggregates are domain objects that derive their current state by replaying events from a stream.
The ShoppingCart aggregate starts empty and applies each event one by one.
After replaying all events, the aggregate reflects the current state.
Aggregates also enforce business rules before new events are appended.

Projections are read models built from events.
While aggregates give you the state of a single stream, projections can combine data from multiple streams to create optimized views for querying.
For example, a "Product Popularity" projection might track how many times each product was added across all carts.

Event Sourcing is not a replacement for CRUD.
It is a different approach that shines in specific scenarios.
We will explore when to use it at the end of this post.

Now let's build a real application to see these concepts in action.

Overview of the Shopping Cart Application

We will build a Shopping Cart API that demonstrates all the core Event Sourcing concepts.

Here is what our application supports:

Commands (write side):

Create a new cart
Add items to the cart
Remove items from the cart
Change item quantities
Checkout the cart
Confirm the order

Queries (read side):

Get cart details (from an inline projection)
Get product popularity rankings (from an async cross-stream projection)

Domain events:

CartCreated
ItemAdded
ItemRemoved
ItemQuantityChanged
CartCheckedOut
OrderConfirmed

Project Structure

The application follows Vertical Slice Architecture with three projects:

ShoppingCart.Domain contains the pure domain model: event records and the aggregate.

ShoppingCart.Features contains the vertical slices: each feature has its own folder with an endpoint, handler, and optional validator. It also contains the projections. This project uses Marten, Carter, ErrorOr, and FluentValidation.

ShoppingCart.WebApi is the host project that wires everything together: Marten configuration, dependency injection, and the ASP.NET Core pipeline.

This structure is similar to what I use in my Modular Monolith projects, but simplified for a single module.

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-event-sourcing-in-dotnet-with-marten-and-postgresql