DEV Community: Manohari Jayachandran

Dependency Injection in Azure Functions with C#: The Isolated Worker Model, Explained

Manohari Jayachandran — Mon, 12 Oct 2026 15:59:52 +0000

Why this post exists

Most production problems in Azure Functions are not logic bugs. They are lifetime bugs: an HttpClient created on every call, a Singleton quietly holding a Scoped object, a "shared" service that is not actually shared. All of them come from the same gap, which is not knowing how dependency injection works inside a function app. This post closes that gap using one complete order-processing example.

In-process versus isolated worker

Think of a building. An in-process function app plugs into the host's own wiring. It shares the host's power supply, so it also shares the host's limits, including which .NET version and package versions it can use. An isolated worker app has its own power supply: it runs as a separate process, with its own Program.cs, its own dependency container and its own choice of .NET version.

Important date: Microsoft ends support for the in-process model on November 10, 2026. .NET 8 support also ends that date. Functions 4.x isolated supports .NET 10, 9, 8 and .NET Framework 4.8. For anything new, use the isolated worker model. Everything below assumes it.

The Program.cs of a Functions app

In the isolated model you write the entry point yourself. This is where dependency injection starts: you register services, the host builds the container once, and every function can ask for those services.

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((context, services) =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();

        services.Configure<OrderProcessingOptions>(
            context.Configuration.GetSection("OrderProcessing"));

        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<INotificationSender, EmailNotificationSender>();
    })
    .Build();

host.Run();

Newer templates also offer a builder style that looks like an ASP.NET Core minimal app:

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.AddScoped<IOrderRepository, OrderRepository>();
builder.Services.AddScoped<INotificationSender, EmailNotificationSender>();

builder.Build().Run();

Both do the same job. Use whichever your template generated.

Logging note: with Application Insights enabled in isolated mode, a default filter hides anything below Warning, so your LogInformation calls may not appear. Remove that rule:

.ConfigureLogging(logging =>
{
    logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        var rule = options.Rules.FirstOrDefault(r => r.ProviderName ==
            "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (rule is not null) options.Rules.Remove(rule);
    });
})

The example: processing orders from Service Bus

Orders arrive as JSON messages on a Service Bus queue called incoming-orders. The function validates the order, saves it, and sends a confirmation. Three things need injecting: a repository, a notification sender, and settings.

The model, options and interfaces

public record Order(string Id, string CustomerEmail, decimal Amount);

public class OrderProcessingOptions
{
    public decimal MaxOrderAmount { get; set; } = 100000m;
}

public interface IOrderRepository
{
    Task SaveAsync(Order order);
}

public interface INotificationSender
{
    Task SendAsync(string recipient, string message);
}

The function class

public class ProcessOrderFunction
{
    private static readonly JsonSerializerOptions JsonOptions =
        new() { PropertyNameCaseInsensitive = true };

    private readonly IOrderRepository _orderRepository;
    private readonly INotificationSender _notificationSender;
    private readonly OrderProcessingOptions _options;
    private readonly ILogger<ProcessOrderFunction> _logger;

    public ProcessOrderFunction(
        IOrderRepository orderRepository,
        INotificationSender notificationSender,
        IOptions<OrderProcessingOptions> options,
        ILogger<ProcessOrderFunction> logger)
    {
        _orderRepository = orderRepository;
        _notificationSender = notificationSender;
        _options = options.Value;
        _logger = logger;
    }

    [Function("ProcessOrder")]
    public async Task Run(
        [ServiceBusTrigger("incoming-orders", Connection = "ServiceBusConnection")]
        string message)
    {
        var order = JsonSerializer.Deserialize<Order>(message, JsonOptions)
            ?? throw new InvalidOperationException("Message body was not a valid order.");

        if (order.Amount <= 0 || order.Amount > _options.MaxOrderAmount)
            throw new InvalidOperationException($"Order {order.Id} amount is out of range.");

        await _orderRepository.SaveAsync(order);
        await _notificationSender.SendAsync(order.CustomerEmail, $"Order {order.Id} received.");

        _logger.LogInformation("Processed order {OrderId}", order.Id);
    }
}

Notice what the function does not do: it never creates a repository, a sender or a connection itself. It asks for them in the constructor. It logs the order id, not the customer email, so personal data stays out of your logs. Throwing on a bad order lets Service Bus retry and eventually dead-letter the message, which is the behaviour you want.

How dependencies get resolved

The power-outlet analogy: the function class is a lamp, the constructor is its plug, and the registrations in Program.cs are the wiring in the walls. The lamp never builds a power station. It plugs in. Step by step:

Start: the worker process starts and runs Program.cs. Your registrations are collected in IServiceCollection, the blueprint.
Build: Build() turns the blueprint into a working container. The power is on.
A message arrives: the Functions host receives an order from incoming-orders and hands it to the worker.
Scope created: the worker creates a new scope for this one invocation.
Constructor resolved: the container sees ProcessOrderFunction needs an IOrderRepository, an INotificationSender, IOptions and ILogger. It builds each one, and anything those depend on, recursively.
Run called: Run executes with the finished object. When it returns, the scope ends and Scoped services are disposed.

Lifetimes in Functions

Transient: a new instance every time something asks. Scoped: one instance per invocation. Singleton: one instance per host instance.

That last phrase is the one people miss. When your function app scales out, Azure runs several host instances. Each has its own container, so each has its own Singleton. In the outlet analogy: a Singleton is the main electrical panel of a building, but a scaled-out app is several buildings, each with its own panel. Never use a Singleton to hold state you expect to be shared across the whole app.

A sensible default: register repositories and senders as Scoped, stateless helpers as Singleton, and use AddHttpClient for HTTP.

The HttpClient mistake

Wrong version:

[Function("CallPartner")]
public async Task Run([ServiceBusTrigger("partner-calls")] string message)
{
    using var client = new HttpClient();   // new socket every call
    var response = await client.GetAsync("https://partner.example.com/api/status");
}

Issues:

Every invocation opens new connections. Disposing the client does not release the sockets immediately, so under load you hit socket exhaustion.
The base address and headers are hard-coded inside the function.
It cannot be mocked in a unit test.

Right version:

services.AddHttpClient<IPartnerClient, PartnerClient>(client =>
    client.BaseAddress = new Uri(context.Configuration["PartnerApi:BaseUrl"]!));

PartnerClient takes an HttpClient in its constructor, and the function takes an IPartnerClient. The factory manages connection pooling and lifetimes for you.

Captive dependency in Functions

A captive dependency is a long-lived service holding on to a short-lived one.

services.AddDbContext<OrderDbContext>(...);                  // Scoped
services.AddSingleton<IOrderRepository, OrderRepository>();   // MISTAKE

The Singleton repository captures the first DbContext it receives and keeps it for the life of the host instance. Functions can run several invocations concurrently on one host instance, so they now share one DbContext, which is not thread-safe. You get random, hard-to-reproduce errors. The fix: make the repository Scoped so it gets a fresh DbContext with every invocation.

Configuration and secrets

Locally, settings live in local.settings.json, which you never commit:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "ServiceBusConnection__fullyQualifiedNamespace": "myns.servicebus.windows.net",
    "OrderProcessing__MaxOrderAmount": "100000"
  }
}

In Azure, the same names are Application Settings. The double underscore maps to the colon in configuration, so OrderProcessing_MaxOrderAmount becomes the OrderProcessing:MaxOrderAmount key that IOptions binds to. The ServiceBusConnection_fullyQualifiedNamespace form uses an identity-based connection, so the function authenticates with its Managed Identity instead of a connection string.

For genuine secrets, use a Key Vault reference as the value of an app setting:

@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/secrets/PartnerApiKey/)

Your code just reads the setting. It never knows the secret lives in Key Vault.

Unit testing the function

This is the payoff. Because the function takes interfaces, a test can hand it mocks and run without Azure.

private static ProcessOrderFunction CreateFunction(
    Mock<IOrderRepository> repo, Mock<INotificationSender> sender) =>
    new(repo.Object, sender.Object,
        Options.Create(new OrderProcessingOptions { MaxOrderAmount = 1000m }),
        NullLogger<ProcessOrderFunction>.Instance);

[Fact]
public async Task Run_SavesOrderAndNotifies_WhenOrderIsValid()
{
    var repo = new Mock<IOrderRepository>();
    var sender = new Mock<INotificationSender>();
    var function = CreateFunction(repo, sender);

    await function.Run("""{"id":"ORD-1","customerEmail":"a@example.com","amount":49.99}""");

    repo.Verify(r => r.SaveAsync(It.Is<Order>(o => o.Id == "ORD-1")), Times.Once);
    sender.Verify(s => s.SendAsync("a@example.com", It.IsAny<string>()), Times.Once);
}

[Fact]
public async Task Run_Throws_AndSavesNothing_WhenAmountExceedsMaximum()
{
    var repo = new Mock<IOrderRepository>();
    var sender = new Mock<INotificationSender>();
    var function = CreateFunction(repo, sender);

    await Assert.ThrowsAsync<InvalidOperationException>(() =>
        function.Run("""{"id":"ORD-2","customerEmail":"a@example.com","amount":5000}"""));

    repo.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Never);
    sender.Verify(s => s.SendAsync(It.IsAny<string>(), It.IsAny<string>()), Times.Never);
}

Problem scenario and strategy

The problem: an inherited function builds its own SqlConnection, HttpClient and EmailSender inside Run. Under load it throws socket errors, it cannot be tested, and the connection string is hard-coded.

The strategy:

Extract an interface for each dependency: repository, partner client, email sender.
Register each in Program.cs with the correct lifetime: Scoped for data access, AddHttpClient for HTTP.
Move credentials out of code: Managed Identity for Azure resources, Key Vault references for real secrets.
Move tunable values into an options class bound with IOptions.
Inject everything through the constructor.
Write unit tests with mocks to lock in the behaviour.
Redeploy and watch Application Insights: the socket errors disappear because connections are now pooled by the factory.

Key lessons

Use the isolated worker model: in-process support ends Nov 10, 2026
Program.cs is where registrations live, and the container is built once
Scoped means per invocation; Singleton means per host instance, not per app
Never new up HttpClient in a function: use AddHttpClient
Never let a Singleton depend on a Scoped service
Configuration binds through IOptions; secrets belong in Key Vault
Interfaces make functions unit-testable without Azure

Summary

Dependency injection in Azure Functions is the same dependency injection you know from ASP.NET Core, with two differences worth remembering: Program.cs is your responsibility in the isolated model, and a Singleton lives per host instance. Get the lifetimes right, inject through constructors, keep secrets out of code, and your functions become reliable, configurable and testable.

More on these topics: Azure posts · C# posts

ASP.NET Core Middleware: The Request Pipeline, Explained

Manohari Jayachandran — Tue, 06 Oct 2026 16:58:07 +0000

The Dependency Injection post covered the first half of Program.cs, everything on builder.Services, the registry that gets built before the app starts. This post covers the second half: everything after builder.Build(), the middleware pipeline. Lines like app.UseAuthentication() and app.MapControllers() get copied between projects constantly, usually without anyone being sure why they sit in the order they do. The Product API from earlier posts is the working example throughout.

What Middleware Actually Is

Middleware is a component that sits in the path of every HTTP request. Each one receives the request, can do some work, and then either passes the request on to the next component or stops it right there and responds itself. Together, the chain of middleware is called the request pipeline.

Think of airport security. Before you reach your gate, you pass through a series of checkpoints, passport control, a baggage scan, a boarding pass check. Each checkpoint inspects you, and each one makes a decision: wave you through to the next checkpoint, or stop you right there. If passport control rejects you, you never reach the baggage scan at all. The gate at the end is the endpoint, your controller action, and it only ever sees passengers who cleared every checkpoint before it.

The Request Goes In, and the Response Comes Back Out

A middleware component doesn't just run once. It gets a next delegate representing the rest of the pipeline. Code written before calling next() runs on the way in; code written after runs on the way back out, once everything further down the pipeline has finished.

var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("1 - request going in");
    await next();
    Console.WriteLine("4 - response coming back out");
});

app.Use(async (context, next) =>
{
    Console.WriteLine("2 - request going in");
    await next();
    Console.WriteLine("3 - response coming back out");
});

app.MapGet("/", () => "Hello");

// Output for one request, in order:
// 1 - request going in
// 2 - request going in
//     (the endpoint runs here)
// 3 - response coming back out
// 4 - response coming back out

The first middleware registered is the first one the request hits, and the last one the response passes through. In the airport picture, that's the passenger leaving through the same checkpoints in reverse order on the way back out.

Short-Circuiting: Stopping the Request Early

If a middleware doesn't call next(), nothing after it runs. The request stops there, and that middleware writes the response itself. This is how authentication, rate limiting, and API key checks reject a request before it ever reaches a controller.

// A simple API key check. The expected key comes from
// configuration - never hardcoded in the class, the same
// rule from the CRUD post
var expectedKey = app.Configuration["ApiKey"];

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.TryGetValue("X-Api-Key", out var providedKey)
        || providedKey != expectedKey)
    {
        context.Response.StatusCode = StatusCodes.Status401Unauthorized;
        await context.Response.WriteAsync("Missing or invalid API key.");
        return;   // no next() call - the pipeline stops here
    }

    await next();
});

Use vs Run vs Map

Three methods add to the pipeline, and they do genuinely different jobs.

app.Use adds middleware that receives a next delegate. It can do work, call next() to continue, or skip next() to short-circuit. It's the most common choice.
app.Run adds terminal middleware, it has no next delegate at all, so whatever reaches it ends there, and it's used for the very last step of a pipeline.
app.Map branches the pipeline, requests whose path starts with the given path go down the branch, and everything else continues on the main pipeline.

// Map branches off a separate mini-pipeline for /health
app.Map("/health", branch =>
{
    branch.Run(async context =>
        await context.Response.WriteAsync("Healthy"));
});

// Run at the end of the main pipeline - anything that
// reaches this point goes no further
app.Run(async context =>
    await context.Response.WriteAsync("End of the line."));

In the airport picture: Use is a normal checkpoint, Run is the final gate, and Map is a separate lane, say crew-only, that splits off before the main queue.

Order Matters: It Is the Behavior

Middleware runs in exactly the order it's registered, so reordering lines changes what the application actually does. A typical, correctly ordered pipeline for an API looks like this.

app.UseExceptionHandler("/error");   // 1. catch errors from everything below
app.UseHttpsRedirection();           // 2. redirect HTTP to HTTPS
app.UseStaticFiles();                // 3. serve static files early
app.UseRouting();                    // 4. work out which endpoint matches
app.UseCors();                       // 5. cross-origin rules
app.UseAuthentication();             // 6. WHO is calling?
app.UseAuthorization();              // 7. are they ALLOWED to do this?
app.MapControllers();                // 8. run the matched endpoint

Why the order is what it is.

Exception handling goes first, because an exception handler only catches exceptions thrown by middleware registered after it, put it last and it catches almost nothing, put it first and it wraps the entire pipeline.
Authentication goes before authorization, because authorization decides whether a caller is allowed to do something, and that decision depends on knowing who the caller is, which is authentication's job, the same distinction covered in the Authentication vs Authorization post on this blog.
Routing goes before the middleware that needs to know which endpoint was matched, authorization, for example, can read metadata from the matched endpoint, like an Authorize attribute, which only exists once routing has run.

This is the practical meaning of "order matters": the pipeline isn't a list of independent features, it's a sequence where each step relies on what the earlier steps already established.

Writing Custom Middleware: A Request Timing Example

Inline app.Use lambdas are fine for small things, but anything non-trivial belongs in its own class. A middleware class takes a RequestDelegate, the next step, in its constructor, and exposes an InvokeAsync method that receives the HttpContext.

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(
        RequestDelegate next,
        ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);          // everything else runs here

        stopwatch.Stop();
        _logger.LogInformation(
            "{Method} {Path} responded {StatusCode} in {ElapsedMs} ms",
            context.Request.Method,
            context.Request.Path,
            context.Response.StatusCode,
            stopwatch.ElapsedMilliseconds);
    }
}

// Registered in Program.cs
app.UseMiddleware<RequestTimingMiddleware>();

This uses the before-and-after structure directly: the stopwatch starts on the way in, and the log line is written on the way back out, once the status code is actually known. Note what gets logged, method, path, status, duration. Not headers, not tokens, nothing sensitive, which is the logging lesson from the CRUD post applied to a real piece of code.

A Lifetime Gotcha That Connects Back to the DI Post

A conventional middleware class is constructed once, when the application starts, and that single instance handles every request for the app's entire lifetime. That makes it behave like a Singleton, which means anything injected through its constructor is effectively captured for the whole app lifetime too.

// WRONG - a Scoped service injected into the constructor
// of a middleware that lives for the whole app lifetime.
// This is the captive dependency problem again.
public class AuditMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IProductService _productService;   // Scoped!

    public AuditMiddleware(RequestDelegate next, IProductService productService)
    {
        _next = next;
        _productService = productService;
    }
    // ...
}

// RIGHT - Scoped services go in the InvokeAsync parameters.
// They are resolved fresh, per request, by the DI container.
public class AuditMiddleware
{
    private readonly RequestDelegate _next;

    public AuditMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(
        HttpContext context,
        IProductService productService)   // resolved per request
    {
        // use productService safely here
        await _next(context);
    }
}

The rule: constructor parameters on a middleware should be things safe to hold for the app's whole lifetime, like ILogger of T or configuration. Anything Scoped goes on InvokeAsync. There is also a factory-based alternative, IMiddleware, which is registered in DI and activated per request, a reasonable option when a middleware genuinely needs several Scoped dependencies.

Global Exception Handling: The Proper Fix From the CRUD Post

The CRUD post flagged two exception problems: errors swallowed silently, and ex.ToString() returned directly to the caller, leaking the stack trace. Handling errors in a try/catch inside every controller action doesn't scale, each one handles it a little differently, and one of them will eventually get it wrong. A single exception-handling middleware, registered first, fixes this in one place.

public class GlobalExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<GlobalExceptionMiddleware> _logger;

    public GlobalExceptionMiddleware(
        RequestDelegate next,
        ILogger<GlobalExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            // Full detail, including the stack trace, goes to the
            // LOGS - visible to the team, never to the caller
            _logger.LogError(ex,
                "Unhandled exception for {Method} {Path}",
                context.Request.Method,
                context.Request.Path);

            // If the response has already started, headers are
            // already sent and a new status code can't be set
            if (context.Response.HasStarted)
            {
                throw;
            }

            context.Response.StatusCode = StatusCodes.Status500InternalServerError;

            var problem = new ProblemDetails
            {
                Status = StatusCodes.Status500InternalServerError,
                Title = "An unexpected error occurred."
            };

            // Generic, safe message to the caller - no exception
            // text, no stack trace, no internal paths
            await context.Response.WriteAsJsonAsync(problem);
        }
    }
}

// Program.cs - registered FIRST, so it wraps everything
app.UseMiddleware<GlobalExceptionMiddleware>();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

Because it's registered first, it wraps the entire pipeline: an exception thrown from authentication, a controller, a service, or the database layer all land in the same catch block. This is the structural version of the fix from the CRUD post, log the full exception internally, return only a generic message to the caller. ASP.NET Core also ships built-in options for this, app.UseExceptionHandler, and in .NET 8 and later the IExceptionHandler interface, worth knowing exist, but writing it by hand once is the clearest way to see what they're actually doing.

Problem Scenario and Solving Strategy

The problem: every controller action in the Products API has its own try/catch. Some return ex.ToString() to the caller, some swallow the error and return 200, some log and some don't. Nobody can say how long requests take, and a recent outage took hours to diagnose because the errors weren't logged consistently.

THE STRATEGY, STEP BY STEP:

Recognize this is a cross-cutting concern - error handling and timing apply to EVERY request, so they don't belong repeated inside individual controller actions
Write a GlobalExceptionMiddleware (above) that logs the full exception internally and returns a generic ProblemDetails response - and register it FIRST in the pipeline, so it wraps everything after it
Remove the per-action try/catch blocks that only existed to handle unexpected errors - the middleware now covers them, consistently
Write a RequestTimingMiddleware (above) that logs method, path, status, and duration for every request - never headers or tokens
Register both before authentication, so even rejected requests (401s) get timed and any exception thrown during authentication is still caught
Keep constructor parameters on both middleware limited to singleton-safe services (ILogger), and put any Scoped dependency on InvokeAsync, so the lifetime rule from the DI post isn't broken
The next outage now shows up in the logs with a full stack trace and the exact request that triggered it, while callers only ever see a generic 500

Key Lessons

Middleware is a chain of components each request passes through, each one can do work, pass the request on, or stop it and respond itself.

Code before await next() runs on the way in; code after it runs on the way back out, in reverse order, which is how a timing middleware can know the final status code.

Not calling next() short-circuits the pipeline, which is how authentication and API key checks reject requests before they reach a controller.

Use adds middleware that can continue or stop, Run is terminal with no next, and Map branches the pipeline for a specific path.

Order is the behavior: an exception handler only catches what's registered after it, and authentication has to come before authorization because authorization depends on knowing who the caller is.

A conventional middleware class is constructed once for the app's lifetime, so Scoped services belong on InvokeAsync, not in the constructor, the same captive dependency problem from the DI post.

A global exception middleware, registered first, replaces scattered try/catch blocks and fixes the leaked stack trace problem from the CRUD post in a single place.

Summary

The DI post explained the first half of Program.cs: a registry of services, built before the app starts. This post covers the second half: a pipeline of middleware, where every request travels in through each component and the response travels back out in reverse. Each component can pass the request along or stop it, which is how authentication rejections and API key checks work. Order isn't cosmetic, an exception handler only protects what comes after it, and authorization needs authentication to have already run. The two halves connect directly, too: a middleware instance lives for the entire app, so the lifetime rules from the DI post apply to it, and Scoped services belong on InvokeAsync. And the exception-handling lessons from the CRUD post finally get a proper home: one middleware, registered first, logging everything internally and returning only a generic error to the caller.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Dependency Injection in .NET: The Complete Mechanics

Manohari Jayachandran — Fri, 02 Oct 2026 16:03:59 +0000

Dependency Injection shows up in nearly every ASP.NET Core project, usually as a few lines in Program.cs that get copy-pasted without much thought about what they actually do. This post goes all the way down to the real mechanics, what IServiceCollection actually is, what BuildServiceProvider does at the moment it runs, and exactly where and how a dependency gets resolved and handed to a class, using the Product API from earlier posts as the working example throughout.

The Core Idea, With an Analogy

Dependency Injection, DI, is a technique where a class receives the objects it depends on from an external source, rather than creating them itself. The class declares what it needs, usually via its constructor, and something else, the DI container, is responsible for actually supplying it.

Think of a lamp and a power outlet. A lamp doesn't generate its own electricity, and it doesn't wire itself directly into the building's breaker box, it just has a standard plug, and trusts that something on the other end of the wall will supply power the moment it's plugged in. The lamp never needs to know where that electricity actually comes from, or how it got there. A class using DI is the lamp; its constructor is the plug; the DI container is the electrical system supplying whatever gets requested, from wherever it's actually sourced.

This analogy carries through the entire rest of this post, every piece of DI's mechanics maps onto some part of this same electrical picture.

One more piece worth adding here: the power actually arriving at that outlet could originate from a solar farm, a hydroelectric dam, or a coal plant, the lamp has no way to tell, and no reason to care. Swap the power source behind the scenes, and every lamp in the building keeps working identically, completely unaware anything changed. This is precisely what happens when a registration is changed from AddScoped() to AddScoped(), ProductService, the "lamp" in this picture, keeps working exactly the same either way, because it only ever depended on the standard plug shape, the IProductRepository interface, never on which specific power plant was actually wired in behind it.

The Three Lifetimes: Transient, Scoped, Singleton

When you register a dependency, you also specify how long a single instance of it should live before a new one gets created. .NET's DI container offers three lifetimes, each genuinely different.

Transient means a brand new instance is created every single time it's requested, even multiple times within the same HTTP request.
Scoped means one instance is created per HTTP request, per "scope," and that same instance is reused for every class that asks for it within that one request.
Singleton means one instance is created the first time it's requested, and that exact same instance is reused for the entire remaining lifetime of the application, across every request, forever, until the app restarts.

Continuing the power outlet analogy:
Transient is like a disposable battery pack, plugged in fresh, used once, discarded, with a brand new one supplied the next time anything needs power.
Scoped is like the electricity supplied to one specific conference room for the duration of a single meeting, everyone in that room draws from the same circuit while the meeting is happening, but a new meeting gets its own fresh circuit session.
Singleton is like the building's one main electrical panel itself, there's exactly one, installed when the building was built, and every single outlet draws from that same one panel for the building's entire lifetime.

// Transient - genuinely stateless helpers, like a
// simple calculator or formatter with no stored state
builder.Services.AddTransient<IPriceFormatter, PriceFormatter>();

// Scoped - anything that should be consistent WITHIN
// one request, but not shared ACROSS requests - most
// commonly, anything wrapping a DbContext
builder.Services.AddScoped<IProductRepository, ProductRepository>();

// Singleton - genuinely shared, thread-safe state that
// should exist exactly once for the whole app, like
// an in-memory cache
builder.Services.AddSingleton<IMemoryCache, MemoryCache>();

IServiceCollection: The Registry Being Built

builder.Services in Program.cs is an instance of IServiceCollection, think of it as a list of entries, each one saying "here's an interface, and here's what concrete class, and lifetime, to use when something asks for it." Critically, at this point, nothing has actually been built yet, it's purely a registry being assembled before the application starts running.

In the outlet analogy, this is the building's electrical blueprint, drawn up before construction even starts, "this room gets its own circuit, that one shares the main panel." No wire is actually live yet. It's a plan an electrician is still writing down.

var builder = WebApplication.CreateBuilder(args);

// Every one of these lines ADDS AN ENTRY to the
// IServiceCollection - none of them actually CREATE
// an object yet
builder.Services.AddDbContext<ProductDbContext>(options =>
    options.UseSqlServer(connectionString));

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddControllers();

// At this exact point in the code, IServiceCollection
// holds four registration entries - and that's all it
// is: a plan, not yet a functioning container

AddTransient, AddScoped, AddSingleton: What the Call Actually Does

Each of these methods is an extension method on IServiceCollection that adds one entry to that registry, pairing an interface, or a concrete type, with how to construct it, and which of the three lifetimes to use.

builder.Services.AddScoped<IProductRepository, ProductRepository>();

// This single line records, roughly:
// "When something asks for an IProductRepository,
//  construct a ProductRepository to satisfy it,
//  and reuse that same instance for the rest of
//  THIS SPECIFIC request, but build a fresh one
//  for the next request"

// A second, related overload lets you provide the
// construction logic directly, useful when a
// dependency needs manual wiring
builder.Services.AddScoped<IProductRepository>(provider =>
{
    var context = provider.GetRequiredService<ProductDbContext>();
    return new ProductRepository(context);
});
// Here, "provider" is itself the DI container, being
// used to resolve ANOTHER dependency (ProductDbContext)
// needed to construct this one - DI resolving DI

BuildServiceProvider: The Moment the Registry Becomes Real

IServiceCollection is just a plan. Calling .Build() on the WebApplicationBuilder, which internally calls something equivalent to BuildServiceProvider(), takes that entire registry and turns it into a working IServiceProvider, an actual, functioning container capable of constructing real objects on demand.

In the outlet analogy, this is the moment construction finishes and the power actually gets turned on at the main breaker. The blueprint becomes a genuinely live electrical system, every outlet in the building is now capable of actually supplying power the instant something gets plugged into it.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddControllers();

// Before this next line: IServiceCollection, a LIST
// of registration entries. Nothing can be resolved yet.

var app = builder.Build();

// After this line: an actual, LIVE IServiceProvider
// now exists internally, genuinely capable of
// constructing a ProductService (and everything IT
// depends on) the moment something asks for one

Why this distinction matters: you can add as many registrations as you want before Build() is called, but once it's called, the container is effectively locked in for that running application. This is exactly why every builder.Services.Add...() call needs to happen before builder.Build(), never after.

Constructor Injection: Where Resolution Actually Happens

You never write new ProductService() anywhere in application code. Instead, a class simply declares what it needs via its constructor, and the DI container automatically resolves and supplies it the moment that class itself needs to be constructed, typically, for a controller, the moment an HTTP request arrives for one of its actions.

In the outlet analogy, the constructor parameter is the lamp's plug, a standard shape, declaring exactly what kind of power it expects. The lamp itself never asks where the electricity comes from, never traces the wire back to its source. It just plugs in, and power arrives, fully resolved.

public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
        // This constructor parameter is the ENTIRE
        // mechanism - nothing else needs to be written
        // anywhere for this to work correctly
    }
}

Here's what actually happens, step by step, when a request for GET /api/products arrives.

ASP.NET Core needs to construct a ProductsController to handle this request
It looks at the constructor and sees it needs an IProductService
It asks the IServiceProvider (built earlier from the registry) to resolve IProductService
The provider sees IProductService was registered as ProductService (Scoped) - it needs an IProductRepository to construct THAT
The provider recursively resolves IProductRepository too, which itself needs a ProductDbContext, which gets resolved the same way
The ENTIRE chain gets built, in the correct order, automatically, and the fully-constructed ProductsController is handed back, ready to handle the request

This recursive resolution, a dependency needing its own dependencies, resolved automatically in turn, is the actual mechanism behind everything covered in the earlier Repository Pattern and SOLID posts on this blog. Dependency Inversion is the design principle, depend on abstractions; this resolution process is literally what Dependency Injection means by "injection."

Manual Resolution: IServiceProvider.GetService, and Why You Rarely Need It

Constructor injection handles resolution automatically for nearly everything in a typical ASP.NET Core app. Occasionally, code needs to resolve something manually and directly, rather than through a constructor.

// Inside Program.cs, AFTER builder.Build(), for a
// one-off manual resolution (genuinely uncommon in
// normal request-handling code, but useful to know)
using (var scope = app.Services.CreateScope())
{
    var productService = scope.ServiceProvider.GetRequiredService<IProductService>();
    var products = await productService.GetAllAsync();
}

// CreateScope() is specifically important here - it
// creates a genuine SCOPE, so a Scoped dependency
// resolved inside it behaves correctly (one instance
// for this scope), rather than accidentally resolving
// a Scoped service directly from the root provider,
// which is a common and genuinely risky mistake

The Captive Dependency Bug, Explained at the Mechanics Level

An earlier post on this blog named the captive dependency problem, AddSingleton used for something wrapping a DbContext. Now that the actual mechanics are clear, here's precisely why it happens.

builder.Services.AddDbContext<ProductDbContext>(options => ...);
// AddDbContext registers ProductDbContext as SCOPED
// by default - one per request

builder.Services.AddSingleton<IProductRepository, ProductRepository>();
// MISTAKE: when the FIRST request ever comes in, the
// container builds a ProductRepository, which needs a
// ProductDbContext - it resolves ONE, and because
// ProductRepository itself is Singleton, that SAME
// ProductRepository instance (holding that SAME
// ProductDbContext instance) is reused for EVERY
// subsequent request, forever - the Scoped DbContext
// is permanently trapped inside a Singleton, used far
// beyond the single request it was actually designed
// to live for

This is precisely why .NET's DI container actually validates this at runtime in many configurations, and why matching a dependency's lifetime to what it actually wraps, Scoped for anything touching a per-request resource, is a correctness requirement, not just a style preference.

Key Lessons

IServiceCollection, builder.Services, is a registry of entries, pairing an interface, a concrete implementation, and a lifetime, built up before the application starts, not yet a working container.

AddTransient, AddScoped, and AddSingleton all add an entry to that same registry, differing only in which lifetime they specify.

BuildServiceProvider, triggered by builder.Build(), is the exact moment the registry transforms into a live, working IServiceProvider capable of actually constructing objects.

Constructor injection is the entire mechanism for resolution in normal application code, a class declares what it needs, and the container resolves the complete dependency chain recursively and automatically.

Manual resolution via IServiceProvider.GetService, or GetRequiredService, exists for genuine edge cases, and should always happen within a proper scope, CreateScope(), to avoid resolving a Scoped service incorrectly.

The captive dependency bug happens because a Singleton resolves its dependencies exactly once, permanently, trapping a Scoped dependency, like a DbContext, far beyond the single request it was designed to live for.

Summary

Dependency Injection in .NET has three distinct phases: building a registry, IServiceCollection, via AddTransient, AddScoped, and AddSingleton, turning that registry into a working container, BuildServiceProvider, triggered by builder.Build(), and resolving dependencies automatically through constructor injection every time a class needs to be constructed. That third phase is recursive, a dependency's own dependencies get resolved the same way, all the way down, which is the actual mechanism behind everything the SOLID and Repository Pattern posts on this blog described more conceptually. Understanding these three phases precisely is what turns "add this line to Program.cs because the tutorial said so" into a genuine, mechanical understanding of what's actually happening underneath.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Bootstrap for Blazor: Styling the Task Tracker

Manohari Jayachandran — Mon, 28 Sep 2026 20:27:31 +0000

This is the final post in the series. The Task Tracker has been built, refactored, rendered, and made interactive, genuinely working since Part 4, but visually plain, using nothing but default, unstyled HTML elements. This post applies Bootstrap directly on top of that same working Blazor app, with zero changes to the underlying logic, purely visual, closing out the series with something that actually looks presentable.

What Bootstrap Actually Is

Bootstrap is a CSS framework, a large, pre-written collection of CSS classes covering layout, spacing, colors, and common UI components, buttons, cards, navigation bars, so a page can look genuinely designed without writing custom CSS from scratch.

Think of pre-fabricated furniture versus building everything from raw lumber. Bootstrap's classes are like a well-designed furniture catalog, a specific bookshelf, a specific desk, already proportioned and finished correctly. You still arrange the room yourself, the actual layout of your page, but you're not hand-cutting and sanding every piece of wood from scratch.

Getting Bootstrap Into the Project

<!-- In the main HTML host page (index.html for Blazor
     WebAssembly, or _Layout.cshtml/App.razor's host
     page for Blazor Server) -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />

<!-- That single line makes every Bootstrap class used
     throughout this post immediately available across
     the entire Blazor app -->

The Grid System: Rows and Columns, No Custom CSS

Bootstrap's layout is based on a 12-column grid. A row contains one or more columns, and the column widths, col-md-8, col-md-4, should add up to 12 for a clean, full-width layout.

<div class="row">
    <div class="col-md-8">
        <!-- Main content - takes 8 of 12 columns -->
    </div>
    <div class="col-md-4">
        <!-- Sidebar - takes the remaining 4 columns -->
    </div>
</div>

<!-- No manual percentage math, no custom CSS -
     just column counts that add up to 12 -->

Cards: Wrapping Each Task Properly

A card is a bordered, padded container with a consistent visual style, genuinely useful for turning a bare list into something that actually reads as a real UI element, not raw text.

<div class="card mb-2">
    <div class="card-body d-flex justify-content-between align-items-center">
        <span>Write documentation</span>
        <button class="btn btn-sm btn-outline-danger">Delete</button>
    </div>
</div>

<!-- mb-2 adds margin-bottom (spacing between cards)
     d-flex, justify-content-between, and
     align-items-center are Bootstrap's UTILITY classes -
     small, single-purpose classes for common layout
     needs, used here to put the task text and the
     Delete button on opposite ends of the same row -->

Button Variants: Replacing Plain, Unstyled Buttons

<button class="btn btn-primary">Add Task</button>
<button class="btn btn-outline-danger">Delete</button>
<button class="btn btn-outline-secondary">All</button>

<!-- btn-primary - a solid, prominent color for the
     main action (adding a task)
     btn-outline-danger - a red outline, appropriate
     for a destructive action (deleting), without being
     as visually loud as a solid red button everywhere
     btn-outline-secondary - a neutral, low-emphasis
     style, appropriate for the filter buttons, which
     aren't the primary focus of the page -->

A Navbar: Giving the App an Actual Header

<nav class="navbar navbar-dark bg-dark mb-4">
    <div class="container">
        <span class="navbar-brand mb-0 h1">Task Tracker</span>
    </div>
</nav>

<!-- navbar-dark + bg-dark gives a dark background with
     light text automatically color-adjusted for
     contrast - no manual color picking required -->

The Complete Styled Task Tracker

@page "/tasks"

<nav class="navbar navbar-dark bg-dark mb-4">
    <div class="container">
        <span class="navbar-brand mb-0 h1">Task Tracker</span>
    </div>
</nav>

<div class="container">

    <div class="row mb-3">
        <div class="col-md-9">
            <input class="form-control" @bind="newTaskDescription" placeholder="New task..." />
        </div>
        <div class="col-md-3">
            <button class="btn btn-primary w-100" @onclick="AddTask">Add Task</button>
        </div>
    </div>

    <div class="mb-3">
        @foreach (var task in FilteredTasks)
        {
            <div class="card mb-2">
                <div class="card-body d-flex justify-content-between align-items-center">
                    <div class="form-check">
                        <input class="form-check-input" type="checkbox" @bind="task.IsCompleted" />
                        @if (task.IsCompleted)
                        {
                            <s class="ms-2">@task.Description</s>
                        }
                        else
                        {
                            <span class="ms-2">@task.Description</span>
                        }
                    </div>
                    <button class="btn btn-sm btn-outline-danger" @onclick="() => DeleteTask(task)">Delete</button>
                </div>
            </div>
        }
    </div>

    <div class="btn-group">
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "All"'>All</button>
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "Active"'>Active</button>
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "Completed"'>Completed</button>
    </div>

</div>

@code {
    // IDENTICAL to Part 4 - zero logic changes.
    // Every single change in this post is a class
    // attribute added to existing markup
    private List<TaskItem> tasks = new();
    private string newTaskDescription = string.Empty;
    private string currentFilter = "All";

    private IEnumerable<TaskItem> FilteredTasks => currentFilter switch
    {
        "Active" => tasks.Where(t => !t.IsCompleted),
        "Completed" => tasks.Where(t => t.IsCompleted),
        _ => tasks
    };

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }

    private void DeleteTask(TaskItem task) => tasks.Remove(task);
}

Worth noticing directly: the @code block is completely unchanged from Part 4. Every single addition in this post, navbar, card, btn-primary, row and col-md classes, is a CSS class attached to existing markup. This is the practical meaning of separating structure and logic, Blazor's job, from presentation, Bootstrap's job: styling an app doesn't require touching the code that makes it actually work.

The Series, Complete

This closes the WPF, MVVM, Razor, Blazor, Bootstrap series. Part 1 built a working Task Tracker in plain WPF, honestly naming the pain points left in on purpose. Part 2 refactored that exact app into proper MVVM, fixing every one of those pain points directly, tangled logic separated, the missed-refresh bug eliminated structurally, the filtering logic made genuinely unit-testable. Part 3 pivoted to the web, rendering the same task data with Razor, deliberately read-only. Part 4 made that page interactive with Blazor, using C# instead of JavaScript, arriving at genuine feature parity with the WPF and MVVM version, add, check, delete, filter, through a completely different technology stack. Part 5, this post, finished the job visually, applying Bootstrap on top of already-working Blazor logic with zero changes to that logic at all.

One example, five posts, two genuinely different technology stacks, WPF desktop and Blazor web, built to the same functional specification, which is itself a useful thing to be able to say plainly in an interview: the same problem, solved twice, in two different paradigms, understanding what changed and what stayed conceptually the same across both.

Key Lessons

Bootstrap is a pre-written CSS framework, classes for layout, components, and utilities, letting a page look genuinely designed without writing custom CSS from scratch.

The 12-column grid system, row and col-md classes, handles layout proportions without manual percentage math.

Cards, button variants, and the navbar are pre-styled components, dropping a class onto existing markup, not building visual style from raw CSS.

Applying Bootstrap required zero changes to the Blazor @code block, proof that structure and logic and visual presentation are genuinely separable concerns.

Across this five-part series, the same Task Tracker was built twice, in WPF and MVVM, and in Razor, Blazor, and Bootstrap, the same functional requirements, two different technology stacks, each with its own idioms for solving the same underlying problems, keeping UI in sync with data, separating concerns, styling presentation.

Summary

Bootstrap turns a functionally complete but visually plain Blazor app into something genuinely presentable, using a pre-written grid system, styled components, and utility classes, all applied without touching a single line of the underlying Blazor logic. That separation is the point: the same Task Tracker that worked correctly in Part 4 works identically here, just dressed properly. Across all five posts in this series, one example carried through two genuinely different technology stacks, a plain WPF window refactored into proper MVVM, and a Razor page made interactive with Blazor and then styled with Bootstrap, arriving at the same functional result from two different directions, which is exactly the kind of comparative understanding worth having ready for an interview question about either one.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Blazor Fundamentals: Making the Task Tracker Interactive

Manohari Jayachandran — Thu, 24 Sep 2026 15:08:53 +0000

Part 3 built a read-only Task Tracker page with Razor, HTML generated from data, nothing more, deliberately. This post takes that exact same Razor syntax and adds real interactivity on top of it: adding a task, checking a box, deleting one, filtering by status, all using C#, with no JavaScript written anywhere, and no full page reload on any interaction.

What Blazor Actually Is

Blazor is a framework for building interactive web UIs using C# instead of JavaScript. It's built directly on top of Razor syntax, covered in the previous post, the same @ symbol, the same mixing of C# and HTML, with an added layer that makes the page actually respond to user interaction.

Think of Part 3's Razor page as a printed photograph, accurate, but fixed the moment it was generated. Blazor turns that into a live video call instead, the picture keeps updating in real time as things actually change, without needing to print a brand new photograph, reload the whole page, every time something happens.

Components: The Actual Building Block

A Blazor component is a .razor file that combines markup and its C# logic together in one place, genuinely different from WPF's split between a .xaml file and a separate .xaml.cs code-behind file.

@* TaskTracker.razor - markup AND logic, ONE file *@

<h2>Task Tracker</h2>

<p>@completedCount of @tasks.Count tasks completed</p>

@code {
    private List<TaskItem> tasks = new();
    private int completedCount => tasks.Count(t => t.IsCompleted);
}

<!-- The @code block contains genuine C# - fields,
     properties, methods - living directly alongside
     the markup that uses them, in the exact same file -->

Event Handling: @onclick, Wiring a Button to Real CSharp

Blazor provides directives like @onclick that wire a DOM event directly to a C# method, no JavaScript event listener setup required at all.

<input @bind="newTaskDescription" placeholder="New task..." />
<button @onclick="AddTask">Add Task</button>

@code {
    private string newTaskDescription = string.Empty;
    private List<TaskItem> tasks = new();

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }
}

<!-- Clicking the button calls AddTask() directly.
     Blazor automatically re-renders whatever part of
     the page actually changed as a RESULT of that
     method running - no manual "refresh the UI" step,
     similar in spirit to what INotifyPropertyChanged
     did for WPF in the MVVM post, but handled
     automatically by the framework here instead -->

@bind: Two-Way Data Binding

@bind keeps an input element and a C# variable automatically in sync, in both directions, type into the box, the variable updates; change the variable in code, the box reflects it.

<input @bind="newTaskDescription" />

<!-- Typing into this input automatically updates
     newTaskDescription. No manual @onchange handler
     needed to read the typed value - @bind does
     both directions of the sync automatically -->

<input type="checkbox" @bind="task.IsCompleted" />

<!-- The exact same @bind directive, on a checkbox
     this time - checking or unchecking it updates
     task.IsCompleted directly, immediately -->

Blazor Server vs Blazor WebAssembly: A Genuinely Important Distinction

Blazor has two fundamentally different hosting models, and the C# code you write looks nearly identical in both, but where that code actually executes is completely different.

With Blazor Server, your C# code runs on the server. The browser holds a live connection, via SignalR, back to that server, every click, every keystroke, sends a small message to the server, which runs the actual C# and sends back only the specific UI changes needed. The advantage is a smaller initial download and full .NET access. The tradeoff is that it requires a constant, low-latency connection to the server, it doesn't work offline, and every interaction has a small network round-trip.

With Blazor WebAssembly, your C# code is compiled and runs directly inside the browser itself, via WebAssembly, no server round-trip needed for each interaction. The advantage is that it works offline once loaded, with no per-interaction network latency. The tradeoff is a larger initial download, since the .NET runtime itself has to be downloaded to the browser, and some API limitations compared to full server-side .NET.

Think of Blazor Server like a video game streamed from a powerful remote server, the actual game runs elsewhere, your screen just shows the result and sends your button presses back. Blazor WebAssembly is like downloading the entire game and running it natively on your own machine, a bigger download upfront, but no lag once it's running, and no dependency on staying connected to anything.

The Complete Interactive Task Tracker

@page "/tasks"

<h2>Task Tracker</h2>

<div>
    <input @bind="newTaskDescription" placeholder="New task..." />
    <button @onclick="AddTask">Add Task</button>
</div>

<ul>
    @foreach (var task in FilteredTasks)
    {
        <li>
            <input type="checkbox" @bind="task.IsCompleted" />
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
            <button @onclick="() => DeleteTask(task)">Delete</button>
        </li>
    }
</ul>

<div>
    <button @onclick='() => currentFilter = "All"'>All</button>
    <button @onclick='() => currentFilter = "Active"'>Active</button>
    <button @onclick='() => currentFilter = "Completed"'>Completed</button>
</div>

@code {
    private List<TaskItem> tasks = new();
    private string newTaskDescription = string.Empty;
    private string currentFilter = "All";

    private IEnumerable<TaskItem> FilteredTasks => currentFilter switch
    {
        "Active" => tasks.Where(t => !t.IsCompleted),
        "Completed" => tasks.Where(t => t.IsCompleted),
        _ => tasks
    };

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }

    private void DeleteTask(TaskItem task) => tasks.Remove(task);
}

// TaskItem.cs - a plain class, same shape as every
// previous post in this series
public class TaskItem
{
    public string Description { get; set; }
    public bool IsCompleted { get; set; }
}

Worth noticing directly: FilteredTasks is a computed property, not a method that has to be manually called after every change, Blazor automatically re-evaluates it and re-renders the list whenever any value it depends on changes, whether that's currentFilter being set by a button click, or a task's IsCompleted flipping via a checkbox. There is no manual refresh step anywhere in this file, the same category of problem the MVVM post solved for WPF, here solved automatically by the framework itself.

Comparing This to the WPF/MVVM Version

In WPF plus MVVM from Parts 1 and 2, you had a Window or UserControl; in Blazor, that's a Component, a single .razor file. WPF needed XAML plus a separate code-behind file; Blazor combines markup and @code in one file. WPF used Click="Method"; Blazor uses @onclick="Method". WPF used {Binding Property}; Blazor uses @bind="variable". WPF needed INotifyPropertyChanged with manual event wiring; Blazor re-renders automatically, handled by the framework. WPF used ICommand and RelayCommand; Blazor just calls a plain C# method directly.

The underlying goal is genuinely the same across both, keep the UI in sync with changing data, without manual refresh steps, but Blazor folds markup and logic into a single file and handles re-rendering automatically, where WPF and MVVM required more explicit, hand-written plumbing to achieve a similar result.

Key Lessons

A Blazor component combines markup and C# logic in one .razor file, genuinely different from WPF's split between XAML and a separate code-behind file.

@onclick wires a DOM event directly to a C# method, with no JavaScript event listener setup required.

@bind provides automatic two-way synchronization between an input element and a C# variable, type in the box, the variable updates; change the variable, the box updates.

Blazor Server runs C# on the server with a live connection back to the browser; Blazor WebAssembly compiles C# to run directly inside the browser itself, genuinely different tradeoffs in latency, offline support, and initial download size.

Blazor re-renders automatically when a value a component depends on changes, no manual refresh call anywhere, solving the same category of problem MVVM solved for WPF, but handled by the framework rather than hand-written.

What's Next

Part 5, the final post in this series, applies Bootstrap directly to this Blazor Task Tracker, the grid system, styled buttons, cards, and a proper navbar, turning this functional-but-plain interface into something that actually looks presentable.

Summary

Blazor takes the Razor syntax from the previous post and adds genuine interactivity on top of it, using C# instead of JavaScript throughout. Components combine markup and logic in one file. @onclick and @bind replace manual event listener setup with simple, declarative directives. And critically, Blazor handles re-rendering automatically whenever a dependent value changes, the same underlying problem MVVM solved for WPF through INotifyPropertyChanged, here solved by the framework itself rather than requiring hand-written plumbing. The choice between Blazor Server and Blazor WebAssembly is a genuine architectural decision, not a minor detail, since it determines where the actual C# code runs and what tradeoffs that brings.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Razor Syntax Fundamentals: Rendering the Task Tracker

Manohari Jayachandran — Fri, 18 Sep 2026 14:47:55 +0000

Parts 1 and 2 covered WPF and MVVM, a desktop application built and then properly structured. Part 3 pivots to the web, genuinely new territory. Razor is the syntax Blazor, covered in Part 4, is built directly on top of, so this post covers Razor on its own first, deliberately, before any framework gets layered in, the same Task Tracker data from the previous two posts, now rendered as a simple, read-only web page.

What Razor Actually Is

Razor is a syntax for mixing C# directly into HTML, letting a single file describe both the visual structure of a page and the logic that decides what actually gets rendered, no separate templating language to learn, since the logic portions are just genuine C#.

Think of a mail-merge letter template. Most of the letter is fixed, ordinary text, but certain spots contain a placeholder, "Dear [Name]", that gets filled in with real data before the letter is actually printed. Razor works the same way: most of a .cshtml file is plain HTML, but specific spots marked with @ get replaced with real, computed values, or entire blocks of logic, before the page is actually sent to a browser.

The @ Symbol: How Razor Knows Where C# Starts

Everything in a Razor file is treated as plain HTML by default. The @ symbol is the signal that switches into C# mode for whatever comes immediately after it.

<h2>Task Tracker</h2>
<p>You have @Model.Tasks.Count tasks.</p>

<!-- Everything here is plain HTML, rendered exactly
     as written, EXCEPT @Model.Tasks.Count - that
     specific expression is evaluated in C#, and the
     RESULT (a number) is what actually appears in
     the rendered page -->

Razor is genuinely smart about where C# ends and HTML resumes again, it doesn't require an explicit closing symbol for a simple expression like this one, since it can tell from the syntax itself where the C# expression naturally ends.

Mixing C# and HTML Directly: A Small First Example

@{
    var completedCount = Model.Tasks.Count(t => t.IsCompleted);
}

<h2>Task Tracker</h2>
<p>@completedCount of @Model.Tasks.Count tasks completed</p>

<!-- The @{ } block above is a CODE BLOCK - pure C#,
     computing a value, but not directly rendering
     anything itself. The variable it creates
     (completedCount) is then USED further down,
     inside the HTML, with a simple @ expression -->

@foreach: Rendering a List

Razor supports genuine C# control structures directly inside HTML, a @foreach loop generates one copy of whatever HTML sits inside it, once per item.

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>@task.Description</li>
    }
</ul>

<!-- This is a REAL C# foreach loop - the exact same
     syntax used anywhere else in C#. The <li> element
     inside the loop body gets rendered once per task
     in Model.Tasks, with @task.Description substituted
     in each time -->

@if: Conditional Rendering

The same applies to @if and else, genuine C# conditional logic, deciding which HTML actually gets rendered.

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
        </li>
    }
</ul>

<!-- Completed tasks render inside a <s> tag
     (strikethrough) - matching visually what checking
     a box did in the WPF version from Parts 1 and 2.
     Incomplete tasks render in a plain <span> instead -->

Rendering the Complete Task Tracker as a Read-Only Page

@model TaskTrackerViewModel

<h2>Task Tracker</h2>

@{
    var completedCount = Model.Tasks.Count(t => t.IsCompleted);
}

<p>@completedCount of @Model.Tasks.Count tasks completed</p>

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
        </li>
    }
</ul>

@if (!Model.Tasks.Any())
{
    <p><em>No tasks yet.</em></p>
}

<!-- @model at the very top declares WHAT TYPE of data
     this specific Razor file expects to receive - here,
     a TaskTrackerViewModel containing a list of tasks.
     This is what makes Model.Tasks, used throughout the
     rest of the file, actually valid and known at
     compile time -->

// TaskTrackerViewModel.cs - the plain C# class this
// Razor file expects, supplied by whatever is rendering
// the page (a Razor Page or an MVC controller action)
public class TaskTrackerViewModel
{
    public List<TaskItem> Tasks { get; set; }
}

What's Deliberately Not Here Yet

This page is genuinely read-only, there's no way to add a task, check a box, or delete anything from it. That's intentional: Razor by itself describes how to render HTML from data, nothing more. The interactivity, a button that actually does something without a full page reload, a checkbox that actually updates state, is exactly what Blazor, covered in the next post, adds on top of this same Razor syntax.

Key Lessons

Razor mixes real C# directly into HTML using the @ symbol, there's no separate templating language, the logic portions are genuine, ordinary C#.

A code block computes values without directly rendering anything; a simple expression renders a value directly at that exact spot.

@foreach and @if are the exact same C# control structures used anywhere else, just usable directly inside HTML markup.

@model at the top of a file declares the exact type of data that file expects, giving compile-time knowledge of what Model actually contains throughout the rest of the file.

Razor on its own only describes how to render HTML from data, it has no interactivity by itself, which is exactly the gap Blazor fills next.

What's Next

Part 4 covers Blazor, taking this exact Razor syntax and adding real interactivity on top of it, turning the read-only Task Tracker page built here into one where adding, checking, and deleting tasks actually works, without a full page reload.

Summary

Razor lets C# and HTML live in the same file, using @ as the signal for where C# begins, a code block for computing values, a simple expression for rendering one directly, and genuine control structures like @foreach and @if for loops and conditionals. The Task Tracker rendered here is intentionally read-only, since Razor by itself only describes how to turn data into HTML, it has no concept of interactivity on its own. That gap is exactly what the next post's subject, Blazor, exists to fill, building directly on top of everything covered in this one.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

MVVM Explained: Refactoring the Task Tracker, Properly

Manohari Jayachandran — Wed, 16 Sep 2026 15:17:51 +0000

Part 1 built a working Task Tracker in plain WPF, and closed by naming three pain points left visible on purpose, business logic tangled directly with UI code, a manual refresh step that was easy to forget (and one place where it actually was forgotten), and zero ability to unit test the filtering logic without running the full application. This post refactors that exact same app into proper MVVM, fixing all three, one at a time.

What MVVM Actually Is

MVVM stands for Model-View-ViewModel, a pattern that splits an application into three distinct roles, each with exactly one job, so that UI code and business logic never end up tangled together the way they were in Part 1.

The Model is what a Task actually is, its data, Description and IsCompleted, with no UI knowledge whatsoever. The View is the XAML, purely visual, it knows how to display things, and nothing about what a "task" means or how filtering works. The ViewModel is the middleman, it holds the tasks, knows how filtering works, and exposes everything the View needs to bind to, but has no direct reference to any XAML control at all.

Think of a restaurant. The Model is the food itself, the actual dish, made of actual ingredients. The View is the plate and table setting, how it's presented to the customer, purely visual. The ViewModel is the waiter, the one who actually knows what's in the kitchen, takes the order, and carries information back and forth between the kitchen and the table, without the plate ever needing to know how the dish was cooked, and without the kitchen ever needing to know which table it's going to.

The Model: Just Data, Nothing Else

// TaskItem.cs - unchanged in SHAPE from Part 1, but now
// implements INotifyPropertyChanged, covered next
public class TaskItem : INotifyPropertyChanged
{
    private string _description;
    private bool _isCompleted;

    public string Description
    {
        get => _description;
        set { _description = value; OnPropertyChanged(); }
    }

    public bool IsCompleted
    {
        get => _isCompleted;
        set { _isCompleted = value; OnPropertyChanged(); }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string name = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}

INotifyPropertyChanged: How the UI Finds Out Something Changed

In Part 1, updating the UI after a change required manually calling RefreshList(), a step that was easy to forget, and genuinely was forgotten in the checkbox handler. INotifyPropertyChanged fixes this at the source: whenever a property's value actually changes, it raises an event announcing exactly that. The UI, bound to that property, is listening for this event and updates itself automatically, nobody has to remember to tell it anything.

Think of a doorbell versus needing to personally walk around telling every single person in a house that someone arrived. Ring the doorbell once, raise the event, anyone who cares, anyone bound or listening, hears it and reacts automatically, without you tracking down each person individually.

The ViewModel: Where the Actual Logic Now Lives

public class TaskViewModel : INotifyPropertyChanged
{
    private ObservableCollection<TaskItem> _allTasks = new();
    private ObservableCollection<TaskItem> _visibleTasks = new();
    private string _newTaskDescription;
    private string _currentFilter = "All";

    public ObservableCollection<TaskItem> VisibleTasks
    {
        get => _visibleTasks;
        private set { _visibleTasks = value; OnPropertyChanged(); }
    }

    public string NewTaskDescription
    {
        get => _newTaskDescription;
        set { _newTaskDescription = value; OnPropertyChanged(); }
    }

    public ICommand AddTaskCommand { get; }
    public ICommand DeleteTaskCommand { get; }
    public ICommand ShowAllCommand { get; }
    public ICommand ShowActiveCommand { get; }
    public ICommand ShowCompletedCommand { get; }

    public TaskViewModel()
    {
        AddTaskCommand = new RelayCommand(AddTask);
        DeleteTaskCommand = new RelayCommand<TaskItem>(DeleteTask);
        ShowAllCommand = new RelayCommand(() => ApplyFilter("All"));
        ShowActiveCommand = new RelayCommand(() => ApplyFilter("Active"));
        ShowCompletedCommand = new RelayCommand(() => ApplyFilter("Completed"));
    }

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(NewTaskDescription))
        {
            var task = new TaskItem { Description = NewTaskDescription, IsCompleted = false };
            task.PropertyChanged += (s, e) => ApplyFilter(_currentFilter);
            // ^ this ViewModel LISTENS to each task's own
            // PropertyChanged - so checking a box automatically
            // re-applies the current filter, fixing the EXACT
            // bug from Part 1 where checking a box didn't
            // update the Completed filter until a button was
            // clicked again

            _allTasks.Add(task);
            NewTaskDescription = string.Empty;
            ApplyFilter(_currentFilter);
        }
    }

    private void DeleteTask(TaskItem task)
    {
        _allTasks.Remove(task);
        ApplyFilter(_currentFilter);
    }

    private void ApplyFilter(string filter)
    {
        _currentFilter = filter;
        var filtered = filter switch
        {
            "Active" => _allTasks.Where(t => !t.IsCompleted),
            "Completed" => _allTasks.Where(t => t.IsCompleted),
            _ => _allTasks.AsEnumerable()
        };
        VisibleTasks = new ObservableCollection<TaskItem>(filtered);
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string name = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}

Notice what's genuinely absent: no TaskListBox, no TaskInput.Text, no reference to any XAML control anywhere in this entire class. Every single method here operates purely on data and logic, which is exactly what makes it unit-testable, covered further below.

ICommand: Replacing Click Event Handlers

In Part 1, a button's Click="AddTask_Click" called a method directly in code-behind. In MVVM, a button binds to an ICommand property on the ViewModel instead, the View never calls a method directly at all.

// RelayCommand.cs - a small, reusable ICommand
// implementation (a common, standard helper class)
public class RelayCommand : ICommand
{
    private readonly Action _execute;
    private readonly Func<bool> _canExecute;

    public RelayCommand(Action execute, Func<bool> canExecute = null)
    {
        _execute = execute;
        _canExecute = canExecute;
    }

    public bool CanExecute(object parameter) => _canExecute?.Invoke() ?? true;
    public void Execute(object parameter) => _execute();
    public event EventHandler CanExecuteChanged
    {
        add => CommandManager.RequerySuggested += value;
        remove => CommandManager.RequerySuggested -= value;
    }
}

// A generic version for commands needing a parameter,
// like DeleteTaskCommand needing to know WHICH task
public class RelayCommand<T> : ICommand
{
    private readonly Action<T> _execute;
    public RelayCommand(Action<T> execute) => _execute = execute;
    public bool CanExecute(object parameter) => true;
    public void Execute(object parameter) => _execute((T)parameter);
    public event EventHandler CanExecuteChanged;
}

The View: Now Purely Visual

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <Window.DataContext>
        <local:TaskViewModel />
    </Window.DataContext>

    <DockPanel Margin="10">

        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal" Margin="0,0,0,10">
            <TextBox Text="{Binding NewTaskDescription, UpdateSourceTrigger=PropertyChanged}" Width="250" Margin="0,0,10,0" />
            <Button Content="Add Task" Command="{Binding AddTaskCommand}" />
        </StackPanel>

        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Center">
            <Button Content="All" Command="{Binding ShowAllCommand}" Margin="5" />
            <Button Content="Active" Command="{Binding ShowActiveCommand}" Margin="5" />
            <Button Content="Completed" Command="{Binding ShowCompletedCommand}" Margin="5" />
        </StackPanel>

        <ListBox ItemsSource="{Binding VisibleTasks}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <CheckBox IsChecked="{Binding IsCompleted}" />
                        <TextBlock Text="{Binding Description}" Margin="10,0,0,0" />
                        <Button Content="Delete"
                                Command="{Binding DataContext.DeleteTaskCommand,
                                          RelativeSource={RelativeSource AncestorType=Window}}"
                                CommandParameter="{Binding}"
                                Margin="20,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

    </DockPanel>
</Window>

Notice: zero Click= or Checked= event handlers anywhere. Every interaction is a binding or a command. This XAML file has no paired logic in MainWindow.xaml.cs at all, the code-behind file is now essentially empty.

The Three Pain Points From Part 1, Fixed Directly

Pain point one was business logic tangled with UI code. This is fixed: AddTask, DeleteTask, and ApplyFilter live entirely in TaskViewModel, with zero references to any XAML control. The View contains no logic at all.

Pain point two was the manual RefreshList() that had to be remembered. This is fixed: INotifyPropertyChanged means the UI updates itself the moment VisibleTasks changes, or the moment any individual TaskItem's IsCompleted changes. There's no refresh step to forget, because there's no refresh step at all, the exact checkbox bug from Part 1 is now structurally impossible, not just fixed by remembering harder next time.

Pain point three was that the filtering logic couldn't be unit tested. This is fixed too, covered next.

The Real Payoff: Genuinely Unit-Testable Filtering Logic

public class TaskViewModelTests
{
    [Fact]
    public void ApplyFilter_Active_ReturnsOnlyIncompleteTasks()
    {
        // Arrange - no WPF, no Window, no UI of any
        // kind involved anywhere in this test
        var viewModel = new TaskViewModel();
        viewModel.NewTaskDescription = "Task A";
        viewModel.AddTaskCommand.Execute(null);
        viewModel.NewTaskDescription = "Task B";
        viewModel.AddTaskCommand.Execute(null);
        viewModel.VisibleTasks[0].IsCompleted = true;

        // Act
        viewModel.ShowActiveCommand.Execute(null);

        // Assert
        Assert.Single(viewModel.VisibleTasks);
        Assert.Equal("Task B", viewModel.VisibleTasks[0].Description);
    }
}

This is exactly the kind of test that was impossible in Part 1, filtering logic lived directly inside a Click handler, tightly coupled to TaskListBox. Here, it's plain C# logic on a plain class, tested the same way as everything covered in the earlier unit testing post on this blog.

Key Lessons

Model, View, and ViewModel each have exactly one job, data, visual presentation, and the logic connecting them, and MVVM's real value is keeping those three jobs from ever tangling back together.

INotifyPropertyChanged replaces manual refresh calls with an event the UI listens for automatically, the exact missed-refresh bug from Part 1 becomes structurally impossible, not just less likely.

ICommand replaces Click event handlers with bindable properties on the ViewModel, meaning the View never directly calls a method, it only ever binds to something.

The genuine payoff of this whole refactor is testability, the same filtering logic that required running the full WPF app and clicking buttons in Part 1 is now a plain, fast unit test with zero UI involved.

MVVM isn't extra complexity for its own sake, every piece introduced here directly fixes a specific, named problem from the plain code-behind version.

What's Next

Part 3 shifts to the web, Razor syntax fundamentals, the templating language Blazor is built on top of, covered next before Blazor itself in Part 4.

Summary

MVVM splits an app into a Model (plain data), a View (purely visual XAML), and a ViewModel (the logic connecting them, with no knowledge of any specific UI control), the restaurant analogy of dish, plate, and waiter. Refactoring the exact Task Tracker from Part 1 into this shape fixed every pain point named there directly: tangled logic separated cleanly, the missed-refresh bug eliminated structurally through INotifyPropertyChanged, and the filtering logic made genuinely unit-testable for the first time. Nothing here was added for its own sake, every piece of MVVM introduced in this post exists because a specific, real problem from the plain version needed exactly that fix.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

WPF Fundamentals: Building a Task Tracker, the Plain Way

Manohari Jayachandran — Tue, 15 Sep 2026 18:06:55 +0000

This is Part 1 of a five-part series covering WPF, MVVM, Razor, Blazor, and Bootstrap, each genuinely new territory, explained from the ground up. The example running through this post is a small Task Tracker desktop app, add a task, mark it complete, delete it, filter by status (All, Active, Completed). It's built here using plain, direct code-behind, deliberately without MVVM, the next post in the series takes this exact same app and refactors it into proper MVVM, once the specific problems with this version are visible firsthand rather than described abstractly.

What WPF Actually Is

WPF (Windows Presentation Foundation) is a framework for building desktop applications with rich, flexible user interfaces, using C# for logic and a separate markup language, XAML, to describe the visual layout.

Think of building a house. XAML is the architectural blueprint, it describes where the rooms are, how big the windows are, what the layout looks like. C# code-behind is the electrician and plumber, it makes things actually do something, a light switch that turns on a light, a button that actually adds a task, once the structure is in place.

XAML: The Markup Language, Explained

XAML (eXtensible Application Markup Language) is a declarative way to describe a user interface, what controls exist, how they're arranged, and their visual properties, separately from the C# code that gives them behavior.

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <Grid>
        <TextBox x:Name="TaskInput" />
        <Button Content="Add Task" Click="AddTask_Click" />
    </Grid>

</Window>

<!-- x:Name gives an element an identifier that C#
     code-behind can reference directly (TaskInput.Text,
     for example)
     Click="AddTask_Click" wires this button to a specific
     C# METHOD, written in the paired code-behind file -->

How this compares to something more familiar: XAML plays a similar role to HTML, describing structure and content declaratively, but it's specifically for a desktop window, not a browser page, and its tags map to actual .NET classes, a Button in XAML corresponds directly to the System.Windows.Controls.Button class, rather than browser-rendered HTML elements.

Windows and Controls

A Window is the actual application window itself, the outermost container. Everything else, buttons, text boxes, lists, are controls placed inside it.

TextBox is a single-line text input, where a new task's description gets typed.
Button is a clickable element, triggering a specific action when clicked, adding a task, deleting one.
ListBox displays a scrollable list of items, shows every task currently in the tracker.
CheckBox is a toggle, marks a specific task as complete or not.

Layout Panels: Three Different Philosophies

A layout panel controls how its child elements are actually arranged on screen. WPF offers several, each with a genuinely different approach.

StackPanel stacks children one after another, vertically by default or horizontally, the simplest layout, good for a straightforward list of elements in a row or column.

<StackPanel Orientation="Horizontal">
    <TextBox x:Name="TaskInput" Width="200" />
    <Button Content="Add" Click="AddTask_Click" />
</StackPanel>

Grid arranges children in rows and columns, like a table, giving precise control over exactly where each element sits.

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>
    <StackPanel Grid.Row="0" Orientation="Horizontal">...</StackPanel>
    <ListBox Grid.Row="1" x:Name="TaskListBox" />
</Grid>

DockPanel has children that "dock" to a specific edge, top, bottom, left, right, with the last child typically filling whatever space remains.

<DockPanel>
    <StackPanel DockPanel.Dock="Top">...</StackPanel>
    <ListBox DockPanel.Dock="Bottom" />
</DockPanel>

Think of StackPanel like stacking books on a shelf, one after another. Grid is like a spreadsheet, with precise rows and columns. DockPanel is like sticky notes pressed to the edges of a whiteboard, with whatever's left in the middle.

Event Handling in Code-Behind

"Code-behind" refers to the C# file paired directly with a XAML file, MainWindow.xaml.cs, paired with MainWindow.xaml, this is where the actual logic lives, referencing controls from the XAML by their x:Name.

// MainWindow.xaml.cs
public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
    }

    private void AddTask_Click(object sender, RoutedEventArgs e)
    {
        if (!string.IsNullOrWhiteSpace(TaskInput.Text))
        {
            TaskListBox.Items.Add(TaskInput.Text);
            TaskInput.Clear();
        }
    }
}

// AddTask_Click is wired directly to the Button's
// Click event in the XAML (Click="AddTask_Click").
// This method reaches DIRECTLY into TaskListBox and
// TaskInput - the controls defined in the XAML file -
// by their x:Name

Building the Complete Task Tracker

Here's the full XAML:

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <DockPanel Margin="10">

        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal" Margin="0,0,0,10">
            <TextBox x:Name="TaskInput" Width="250" Margin="0,0,10,0" />
            <Button Content="Add Task" Click="AddTask_Click" />
        </StackPanel>

        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Center">
            <Button Content="All" Click="ShowAll_Click" Margin="5" />
            <Button Content="Active" Click="ShowActive_Click" Margin="5" />
            <Button Content="Completed" Click="ShowCompleted_Click" Margin="5" />
        </StackPanel>

        <ListBox x:Name="TaskListBox">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <CheckBox IsChecked="{Binding IsCompleted}"
                                  Checked="TaskCheckBox_Changed"
                                  Unchecked="TaskCheckBox_Changed"
                                  Tag="{Binding}" />
                        <TextBlock Text="{Binding Description}" Margin="10,0,0,0" />
                        <Button Content="Delete" Click="DeleteTask_Click" Tag="{Binding}" Margin="20,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

    </DockPanel>
</Window>

And the full code-behind:

public partial class MainWindow : Window
{
    private List<TaskItem> _allTasks = new List<TaskItem>();

    public MainWindow()
    {
        InitializeComponent();
    }

    private void AddTask_Click(object sender, RoutedEventArgs e)
    {
        if (!string.IsNullOrWhiteSpace(TaskInput.Text))
        {
            var task = new TaskItem { Description = TaskInput.Text, IsCompleted = false };
            _allTasks.Add(task);
            TaskInput.Clear();
            RefreshList(_allTasks);
        }
    }

    private void DeleteTask_Click(object sender, RoutedEventArgs e)
    {
        var button = (Button)sender;
        var task = (TaskItem)button.Tag;
        _allTasks.Remove(task);
        RefreshList(_allTasks);
    }

    private void TaskCheckBox_Changed(object sender, RoutedEventArgs e)
    {
        var checkBox = (CheckBox)sender;
        var task = (TaskItem)checkBox.Tag;
        task.IsCompleted = checkBox.IsChecked ?? false;
    }

    private void ShowAll_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks);

    private void ShowActive_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks.Where(t => !t.IsCompleted).ToList());

    private void ShowCompleted_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks.Where(t => t.IsCompleted).ToList());

    private void RefreshList(List<TaskItem> tasks)
    {
        TaskListBox.ItemsSource = null;
        TaskListBox.ItemsSource = tasks;
    }
}

public class TaskItem
{
    public string Description { get; set; }
    public bool IsCompleted { get; set; }
}

The Pain Points Worth Noticing (Setting Up the Next Post)

This app genuinely works, but a few things are worth sitting with honestly, since they're exactly what the next post's MVVM refactor addresses directly.

Every single interaction is handled by code directly reaching into UI controls, TaskListBox.ItemsSource, TaskInput.Text, TaskInput.Clear(), the "business logic," what a task is, how filtering works, is tangled together with UI manipulation code in the exact same methods.

RefreshList() has to be called manually, by hand, after every single change, add a task, refresh manually; delete a task, refresh manually; check a box, forgot to refresh at all, the checkbox handler above doesn't call it, so the Completed filter won't reflect a just-checked box until you click a filter button again, a genuinely easy bug to introduce accidentally.

There is no way to unit test any of this logic in isolation, testing whether filtering to Active works correctly requires actually running the full WPF application and clicking buttons, since the filtering logic lives directly inside a Click event handler, tightly coupled to the UI itself.

Key Lessons

XAML is a declarative markup language describing WPF UI structure, playing a similar role to HTML but mapping directly to .NET classes rather than browser elements.

StackPanel, Grid, and DockPanel represent three genuinely different layout philosophies, stacking, table-like precision, and edge-docking, each suited to different UI shapes.

Code-behind directly wires XAML events to C# methods via x:Name references, straightforward, and genuinely workable for a small app like this one.

The specific pain in this version isn't that it's wrong, it's that business logic and UI manipulation code live in the exact same place, making the app harder to test and easier to introduce subtle bugs into, like the missed refresh on checkbox change, as it grows.

What's Next

Part 2 of this series takes this exact Task Tracker and refactors it into proper MVVM, separating what a task is and how filtering works, the ViewModel, from how it's actually displayed, the View, fixing the manual-refresh problem and making the filtering logic genuinely unit-testable for the first time.

Summary

WPF describes a desktop UI declaratively through XAML, with C# code-behind providing the actual behavior, referencing controls directly by name. Layout panels, StackPanel, Grid, DockPanel, offer different ways to arrange those controls on screen. The Task Tracker built here genuinely works, but every interaction reaches directly into UI controls from within event handlers, tangling business logic with UI manipulation, which is precisely the shape of problem MVVM, covered in the next post, exists to solve.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

GitHub Copilot for C# Developers: Setup, Techniques, Agents, and Honest Tradeoffs

Manohari Jayachandran — Thu, 10 Sep 2026 13:57:44 +0000

GitHub Copilot gets mentioned constantly and explained properly rarely, most people know "it suggests code as you type" and stop there. This post covers it from the ground up, using the Product CRUD API from earlier posts as the working example, since that domain is already familiar and lets the focus stay entirely on Copilot itself rather than a new codebase.

What GitHub Copilot Actually Is

Copilot is an AI pair programmer built into your editor, trained on a large body of public code, that suggests code based on the context of what you're currently writing. It is not one single feature, it's actually three genuinely different tools sharing one name.

Inline Suggestions show ghost text as you type, predicting the next line or few lines, press Tab to accept, Esc to dismiss. This is the original, most common form of Copilot.
Copilot Chat is a separate side panel where you ask questions, request explanations of existing code, or ask it to generate something specific through conversation.
Agent Mode is given a broader task rather than a single suggestion, and can plan, edit multiple files, and iterate somewhat autonomously toward completing that task, covered in depth further down.

Think of autocomplete on a phone keyboard, but instead of predicting the next word, it predicts the next several lines of code, based not just on what you just typed, but on the surrounding context of your open files, function names, and comments.

Setting It Up: VS Code

Open the Extensions panel (Ctrl+Shift+X)
Search for "GitHub Copilot"
Install both "GitHub Copilot" (inline suggestions) and "GitHub Copilot Chat" (the chat panel)
Sign in when prompted - this links to your GitHub account, which needs an active Copilot subscription (individual, business, or via an organization)
A small Copilot icon appears in the status bar, bottom-right - click it to confirm it's active

Once installed, ghost-text suggestions appear automatically as you type in any supported file type, including .cs files.

Setting It Up: Visual Studio

Extensions menu -> Manage Extensions
Search "GitHub Copilot"
Install, then restart Visual Studio when prompted
Sign in via the account icon, top-right corner
Copilot Chat opens as a dedicated tool window, accessible via View -> GitHub Copilot Chat

Visual Studio's integration surfaces suggestions the same way - inline, as you type - with Chat available as a separate panel for conversational requests.

Techniques That Genuinely Improve Suggestion Quality

Copilot's suggestions are only as good as the context it has to work with, specific techniques noticeably change what it suggests.

// Writing a clear comment BEFORE the code - this
// genuinely steers the next suggestion
// validate that price is greater than zero and
// stock quantity is non-negative
public bool IsValid(CreateProductDto dto)
{
    // Copilot's suggestion here is shaped directly
    // by the comment above - likely something close to:
    return dto.Price > 0 && dto.StockQuantity >= 0;
}

// Descriptive naming as a strong signal of intent
// A vague name gives Copilot little to work with:
public Task<bool> DoThing(int x) { }

// A descriptive name gives it a genuine, specific
// signal of what the method should actually do:
public Task<bool> ReserveProductStockAsync(int productId) { }
// Copilot's suggested implementation for the second
// version is noticeably more likely to match intent

Keeping related files open matters too. If ProductDto.cs, IProductService.cs, and ProductsController.cs are all open in tabs while writing a new method in ProductService.cs, Copilot's suggestions draw on the actual shape of those related types, property names, method signatures, rather than guessing at a generic, unrelated pattern.

Copilot Chat also has slash commands worth knowing:
/explain explains what a selected block of code actually does
/fix suggests a fix for a selected block with an error
/tests generates unit tests for a selected method
genuinely useful as a starting point, covered further below under the honest cons section.

What "Agent Mode" Actually Means

The terminology here is genuinely confusing right now, worth untangling directly. Inline suggestions and Chat both respond to something you've already written or asked, one piece at a time. Agent mode is given a broader, higher-level task, "implement pagination for the GetAll endpoint," and can plan the necessary steps, edit multiple files, run terminal commands, and iterate somewhat autonomously toward completing that task, checking in with you at key decision points rather than requiring line-by-line approval.

Autocomplete's scope is the next few lines, and you approve every single suggestion, constantly. Chat's scope is one specific question or request per message, and you approve by reading the response and deciding whether to use it. Agent mode's scope is a whole task, potentially spanning several files, and you approve at a higher level, reviewing a batch of changes, or specific decision points, rather than every individual line.

Why this distinction matters practically: agent mode represents a genuine shift in how much you're reviewing versus how much you're trusting the tool to get right on its own, which directly changes how carefully you need to review the eventual output.

The Genuine Pros

Speed on boilerplate is real. DTOs, basic CRUD scaffolding, repetitive patterns, the exact kind of code shown across the CRUD post's good version, Copilot genuinely speeds up writing the first draft of structurally repetitive code.

A fast first draft helps when you already know what correct looks like. Writing the general shape of a method you understand well, then reviewing and adjusting it, is often faster than typing every character by hand.

It can also be a learning aid, used deliberately. Seeing an alternative approach to something you were about to write anyway can surface a pattern or method you didn't know existed, worth treating as a suggestion to evaluate, not an answer to accept.

The Genuine Cons, Including a Real, Concrete Example

Copilot suggests code that statistically resembles patterns it has seen, including patterns that are simply wrong, if that's what surrounds it in context.

// A REAL kind of situation worth being aware of:
// if an older, unrelated file in the same project
// still contained the BAD version's pattern from the
// CRUD post -

var query = "SELECT * FROM Products WHERE Id = " + id;

// - Copilot may suggest something structurally similar
// for a NEW method, simply because that pattern exists
// elsewhere in the codebase it has as context. It does
// not independently know this is a SQL injection
// vulnerability - it's reflecting the surrounding code,
// good or bad, without judgment

A few other genuine cons, stated plainly. There's a real over-reliance risk, accepting suggestions without reading them carefully is an easy habit to fall into, especially for boilerplate that looks right at a glance. Code can be confidently wrong, a suggestion can be syntactically correct, run without error, and still be logically wrong, Copilot has no way to verify business logic correctness, only pattern plausibility. Generated tests can test the wrong thing, /tests can produce a test that passes while checking a condition that doesn't actually matter, or missing the specific failure case, like the ones covered in the unit testing post, that a human would think to add deliberately. And there are genuine licensing and originality questions, a debated topic, since suggested code is generated from patterns in public code, and questions about attribution and originality are worth being aware of, even without a settled, universal answer.

Problem Scenario and Solving Strategy

The problem: in a live coding interview, you're asked to implement a new endpoint with Copilot enabled and visible. You want to use it efficiently without appearing to not understand your own code, and without accidentally accepting a subtly incorrect suggestion under time pressure.

The strategy, step by step:

Write the method signature and a clear, specific
comment BEFORE accepting any suggestion - this alone
demonstrates you're directing the tool, not being
directed by it
Read every suggestion before accepting - out loud if
the format allows it ("this checks for null, then
queries by id... looks right, accepting that") - this
turns an invisible mental step into an audible,
visible one for an interviewer
When a suggestion looks reasonable but you're not
fully certain, say so directly: "I'd want to verify
this handles the not-found case correctly" - genuine,
visible skepticism reads as competence, not hesitation
Use Copilot for the boilerplate parts specifically
(the DTO shape, the basic CRUD structure) and slow
down deliberately for the actual business logic -
this shows judgment about WHEN the tool is
appropriate, not just that it exists
If a suggestion is wrong, say so and correct it
visibly, rather than silently accepting and moving on -
catching and fixing an incorrect suggestion in real
time is a stronger signal than never seeing one at all

Key Lessons

Copilot is three genuinely different tools under one name, inline suggestions, Chat, and agent mode, each with a different scope of autonomy and a different amount of review it actually needs from you.

Clear comments and descriptive naming aren't just good practice for human readers anymore, they're the direct input that shapes what Copilot suggests next.

Agent mode represents a real shift from approving every line to reviewing a batch of changes, worth understanding deliberately rather than treating it as just a faster version of autocomplete.

Copilot reflects the patterns already present in its context, including bad ones, it has no independent judgment about whether a pattern like string-concatenated SQL is actually safe.

The genuine skill isn't generating code quickly, it's reading generated code critically enough to know whether it's actually correct, which is exactly the skill built across the CRUD, Repository Pattern, and Unit Testing posts already on this blog.

Summary

GitHub Copilot is genuinely useful for exactly the kind of repetitive, structurally predictable code shown throughout the CRUD and Repository Pattern posts, but its suggestions are a reflection of surrounding patterns, not a judgment about correctness. Inline suggestions, Chat, and agent mode represent increasing levels of autonomy, each requiring a correspondingly different level of review. Comments and naming aren't just documentation anymore, they're the actual mechanism for getting better suggestions. And the core skill this whole blog has been building toward, understanding SOLID principles, writing testable code, knowing what a correct fix actually looks like, is precisely what makes Copilot's output genuinely useful instead of a fast way to introduce a bug you didn't write yourself.

Originally published on my blog: TechStack Blog

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Unit Testing in C# with xUnit and Moq: Proving the Repository Pattern Actually Pays Off

Manohari Jayachandran — Mon, 07 Sep 2026 14:37:48 +0000

The Repository Pattern post said, more than once, that BookReservationService was "genuinely unit-testable with a mock," because it depends on IBookRepository, an abstraction, rather than a concrete class talking directly to a real database. That claim was never actually backed up with a real test. This post keeps that promise properly, using the exact same Library Book Reservation example, explaining every concept along the way rather than assuming familiarity with testing at all.

The Problem Unit Testing Actually Solves

BookReservationService depends on IBookRepository and INotificationSender. In production, those are backed by a real EF Core repository talking to a real SQL Server database, and a real email-sending service. If you wanted to test BookReservationService's actual logic, does it correctly reserve a book, does it correctly send a notification only when reservation succeeds, testing it against the real versions would mean a real database has to exist and be reachable, test data has to be manually set up and cleaned up afterward, and a real email might actually get sent every time the test runs. This is slow, fragile, and genuinely unpleasant to run repeatedly.

Think of testing a car's dashboard warning lights by actually driving the car empty of oil until the engine seizes, versus using a diagnostic bench that can simulate "oil level: critically low" as an input and simply checking whether the warning light turns on. The bench doesn't need a real engine at all, it just needs to convincingly send the right signal.

What a Mock Actually Is

A mock is a fake object that implements the same interface as a real dependency, but where you, the person writing the test, control exactly what it returns for any given input, without any real database, network call, or external system involved at all.

// The REAL implementation - used in production
public class BookRepository : IBookRepository
{
    // ... talks to a real LibraryDbContext, a real database
}

// A MOCK - used only in tests, created automatically
// by the Moq library, never hand-written by you
var mockRepository = new Mock<IBookRepository>();

// YOU tell the mock exactly what to return when a
// specific method is called with specific arguments
mockRepository
    .Setup(repo => repo.GetByIdAsync(1))
    .ReturnsAsync(new Book { Id = 1, Title = "Test Book", IsAvailable = true });

// From BookReservationService's perspective, this mock
// IS a perfectly valid IBookRepository - it has no way
// to tell the difference between this and a real one

This is the exact payoff of Dependency Inversion from the earlier post: because BookReservationService's constructor only asks for the interface, a test can hand it a completely fake implementation, and the service has no way to know or care.

Setting Up an xUnit Test Project

xUnit is the testing framework, the tool that actually discovers your test methods, runs them, and reports pass or fail. Tests live in a separate project from your main application.

# Creating the test project (terminal / VS Code)
dotnet new xunit -n LibrarySystem.Tests
cd LibrarySystem.Tests
dotnet add reference ../LibrarySystem/LibrarySystem.csproj
dotnet add package Moq

// A minimal first test - [Fact] marks a method as
// a single, standalone test case
public class BookReservationServiceTests
{
    [Fact]
    public void ExampleTest()
    {
        Assert.True(1 + 1 == 2);
    }
}

# Running tests
dotnet test

[Fact] tells xUnit "this method is a test, run it." Assert.True(...), and its many siblings, Assert.Equal, Assert.False, Assert.Null, is how a test states what it actually expects to be true, if the assertion fails, the test fails, and xUnit reports exactly which one and why.

The Arrange-Act-Assert Pattern

Nearly every well-written unit test follows the same three-part shape, and naming it explicitly makes tests dramatically easier to read and write consistently.

[Fact]
public async Task ReserveBookAsync_ReturnsTrue_WhenBookIsAvailable()
{
    // ARRANGE - set up the mocks and the object being tested
    var mockRepository = new Mock<IBookRepository>();
    mockRepository
        .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
        .ReturnsAsync(true);

    var mockNotifier = new Mock<INotificationSender>();

    var service = new BookReservationService(
        mockRepository.Object,
        mockNotifier.Object
    );

    // ACT - call the ONE method actually being tested
    var result = await service.ReserveBookAsync(1, "member@example.com");

    // ASSERT - check the outcome matches what was expected
    Assert.True(result);
}

Think of a science experiment's structure: set up the conditions (Arrange), run the actual experiment (Act), record and check the result against the hypothesis (Assert). Separating these three phases clearly is what makes a test readable at a glance, rather than a tangled block where setup, execution, and checking are all mixed together.

Note the naming convention: MethodName_ExpectedBehavior_Condition. ReserveBookAsync_ReturnsTrue_WhenBookIsAvailable reads almost like a sentence, and immediately tells you what broke just from the test name in a failure report, without needing to open the test method itself.

Verify: Checking That Something Happened, Not Just What Was Returned

Assert checks a return value. Verify, a Moq-specific feature, checks that a specific method on a mock was actually called, which matters when the thing you care about isn't a return value, but a side effect.

[Fact]
public async Task ReserveBookAsync_SendsNotification_WhenReservationSucceeds()
{
    // Arrange
    var mockRepository = new Mock<IBookRepository>();
    mockRepository
        .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
        .ReturnsAsync(true);

    var mockNotifier = new Mock<INotificationSender>();

    var service = new BookReservationService(
        mockRepository.Object,
        mockNotifier.Object
    );

    // Act
    await service.ReserveBookAsync(1, "member@example.com");

    // Assert - VERIFY that SendAsync was actually called,
    // with the correct recipient, EXACTLY once
    mockNotifier.Verify(
        n => n.SendAsync("member@example.com", It.IsAny<string>()),
        Times.Once
    );
}

// It.IsAny<string>() means "don't care about the exact
// message text, just confirm SendAsync was called with
// this specific recipient" - useful when the precise
// wording isn't what the test is actually checking

This test would fail if BookReservationService's ReserveBookAsync method forgot to call the notifier at all, even though the reservation itself might still correctly return true. Assert alone wouldn't have caught that; Verify specifically checks that the interaction actually happened.

Testing the Failure Path: What Should NOT Happen

A genuinely thorough test suite checks the failure case just as carefully as the success case, specifically confirming that something that shouldn't happen, doesn't.

[Fact]
public async Task ReserveBookAsync_ReturnsFalse_WhenBookIsNotAvailable()
{
    // Arrange - the mock is configured to simulate
    // a book that's already reserved
    var mockRepository = new Mock<IBookRepository>();
    mockRepository
        .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
        .ReturnsAsync(false);

    var mockNotifier = new Mock<INotificationSender>();

    var service = new BookReservationService(
        mockRepository.Object,
        mockNotifier.Object
    );

    // Act
    var result = await service.ReserveBookAsync(1, "member@example.com");

    // Assert - the reservation correctly failed
    Assert.False(result);

    // AND, just as importantly - confirm the notification
    // was NEVER sent, since there's nothing to notify about
    mockNotifier.Verify(
        n => n.SendAsync(It.IsAny<string>(), It.IsAny<string>()),
        Times.Never
    );
}

This second assertion, Times.Never, is exactly the kind of check that catches a real bug: if someone later modifies BookReservationService and accidentally moves the notification call outside the if (success) block, this test fails immediately, loudly, and specifically, rather than the bug quietly reaching production where a member gets a confusing "reservation confirmed" email for a book they didn't actually get.

[Theory] and [InlineData]: One Test, Many Inputs

Writing a nearly-identical test method for every input value you want to check is repetitive. [Theory] combined with [InlineData] runs the same test logic once per data row, keeping the test method itself written only once.

[Theory]
[InlineData(1, "member@example.com", true)]
[InlineData(2, "another@example.com", true)]
[InlineData(999, "member@example.com", false)]
public async Task ReserveBookAsync_ReturnsExpectedResult(
    int bookId, string email, bool repositoryReturns)
{
    // Arrange
    var mockRepository = new Mock<IBookRepository>();
    mockRepository
        .Setup(repo => repo.ReserveAsync(bookId, email))
        .ReturnsAsync(repositoryReturns);

    var mockNotifier = new Mock<INotificationSender>();
    var service = new BookReservationService(mockRepository.Object, mockNotifier.Object);

    // Act
    var result = await service.ReserveBookAsync(bookId, email);

    // Assert
    Assert.Equal(repositoryReturns, result);
}

// xUnit runs this ONE method three times, once per
// [InlineData] row, reporting each as its own separate
// pass/fail result - not one combined test

Think of a single, reusable form with blank fields, filled out three different ways, rather than writing three entirely separate forms from scratch that happen to ask the same questions.

What NOT to Unit Test: The Distinction That Matters in an Interview

BookReservationService is unit-tested, with mocks, exactly as shown above. The real BookRepository, the class that actually talks to EF Core and a real database, is not tested this same way. Testing that class against a real (or realistic, disposable) database is called an integration test, a genuinely different kind of test with a different purpose.

A unit test tests one class's logic in isolation, every dependency is mocked, it's fast, milliseconds, no real database, no real network. Example: does BookReservationService call the notifier correctly when a reservation succeeds.

An integration test confirms that multiple real pieces work together correctly, often using a real (or realistic, temporary) database, it's slower, but catches problems mocks physically cannot, a wrong SQL query, a broken EF Core mapping, a real connection string issue. Example: does BookRepository.ReserveAsync actually update the correct row in a real database.

Why this distinction gets asked about directly: a common interview question is some version of "would you unit test your repository class?" The genuinely correct answer is no, not with mocks, because there's nothing left to fake once you're already testing the thing that talks to the real database. That class gets validated through an integration test instead, often using a real test database or an in-memory database provider specifically built for this purpose.

The Complete Test Class

public class BookReservationServiceTests
{
    [Fact]
    public async Task ReserveBookAsync_ReturnsTrue_WhenBookIsAvailable()
    {
        var mockRepository = new Mock<IBookRepository>();
        mockRepository
            .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
            .ReturnsAsync(true);

        var mockNotifier = new Mock<INotificationSender>();
        var service = new BookReservationService(mockRepository.Object, mockNotifier.Object);

        var result = await service.ReserveBookAsync(1, "member@example.com");

        Assert.True(result);
    }

    [Fact]
    public async Task ReserveBookAsync_SendsNotification_WhenReservationSucceeds()
    {
        var mockRepository = new Mock<IBookRepository>();
        mockRepository
            .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
            .ReturnsAsync(true);

        var mockNotifier = new Mock<INotificationSender>();
        var service = new BookReservationService(mockRepository.Object, mockNotifier.Object);

        await service.ReserveBookAsync(1, "member@example.com");

        mockNotifier.Verify(
            n => n.SendAsync("member@example.com", It.IsAny<string>()),
            Times.Once
        );
    }

    [Fact]
    public async Task ReserveBookAsync_ReturnsFalse_WhenBookIsNotAvailable()
    {
        var mockRepository = new Mock<IBookRepository>();
        mockRepository
            .Setup(repo => repo.ReserveAsync(1, "member@example.com"))
            .ReturnsAsync(false);

        var mockNotifier = new Mock<INotificationSender>();
        var service = new BookReservationService(mockRepository.Object, mockNotifier.Object);

        var result = await service.ReserveBookAsync(1, "member@example.com");

        Assert.False(result);
        mockNotifier.Verify(
            n => n.SendAsync(It.IsAny<string>(), It.IsAny<string>()),
            Times.Never
        );
    }

    [Theory]
    [InlineData(1, "member@example.com", true)]
    [InlineData(2, "another@example.com", true)]
    [InlineData(999, "member@example.com", false)]
    public async Task ReserveBookAsync_ReturnsExpectedResult(
        int bookId, string email, bool repositoryReturns)
    {
        var mockRepository = new Mock<IBookRepository>();
        mockRepository
            .Setup(repo => repo.ReserveAsync(bookId, email))
            .ReturnsAsync(repositoryReturns);

        var mockNotifier = new Mock<INotificationSender>();
        var service = new BookReservationService(mockRepository.Object, mockNotifier.Object);

        var result = await service.ReserveBookAsync(bookId, email);

        Assert.Equal(repositoryReturns, result);
    }
}

Key Lessons

A mock is a fake implementation of an interface, entirely controlled by the test, it exists specifically because BookReservationService depends on IBookRepository, the abstraction, rather than a concrete class, which is the direct, practical payoff of Dependency Inversion.

Arrange-Act-Assert is the standard shape of a readable unit test, set up, execute one action, check the result, and naming the sections explicitly, even just as comments, makes tests dramatically easier to follow.

Assert checks a return value; Verify checks that a specific interaction actually happened, both matter, and testing only one of them can miss real bugs.

Testing the failure path deliberately, Times.Never, Assert.False, is just as important as testing the happy path, it's often where the actual bugs hide.

[Theory] and [InlineData] avoid duplicating nearly-identical test methods for different input values.

Unit tests mock every dependency and test one class in isolation; integration tests use real, or realistic, dependencies to confirm multiple real pieces work together, knowing which kind of test fits which class is a genuinely common interview question.

Summary

The Repository Pattern post claimed BookReservationService was "genuinely unit-testable" because it depends on an interface rather than a concrete class, this post is where that claim actually gets demonstrated, with real, runnable tests. A mock stands in for a real dependency, letting a test control exactly what happens without a real database anywhere in sight. Arrange-Act-Assert keeps each test readable. Verify catches missing side effects that a simple return-value check would miss entirely. And knowing the line between a unit test and an integration test, what gets mocked, what doesn't, and why, is exactly the kind of distinction that separates someone who has used a testing framework from someone who actually understands what each type of test is for.

Originally published on my blog: TechStack Blog

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Postman for API Work: Collections, Environment Variables, Secrets, Auth, and Tests

Manohari Jayachandran — Fri, 04 Sep 2026 23:08:24 +0000

Postman is the tool most people use constantly and never actually learn properly, pasting URLs into a blank request, hardcoding a token directly into a header, clicking Send and eyeballing the response. This post covers it the way it's actually meant to be used, with the Product API from the earlier CRUD and Swagger posts as the working example throughout.

Collections and Requests

A Collection is a named folder of related requests, keeping every endpoint for one API grouped together, instead of a scattered pile of unsaved tabs that disappear when Postman restarts.

Think of a filing cabinet drawer labeled "Products API," with individual folders inside for each request type, versus loose papers scattered across a desk. Nothing is lost, nothing has to be rebuilt from memory the next time you need it.

Products API (Collection)
  |- GET All Products
  |- GET Product By Id
  |- POST Create Product
  |- PUT Update Product
  |- DELETE Product

Each request saves its method, URL, headers, body, and any tests written for it, permanently, reusable any time, by anyone the collection is shared with.

Environment Variables

An Environment is a named set of variables, like baseUrl or apiKey, that requests reference using double curly brace syntax, instead of hardcoding literal values. Switching the active environment changes what every request in the collection actually points to, without editing a single request by hand.

Think of a universal remote's device selector. The same physical buttons, play, pause, volume, work identically regardless of which device is currently selected, the remote just sends the command to whatever's active. An environment switch works the same way for your requests.

Request URL, written once:
  {{baseUrl}}/api/products

Dev environment:
  baseUrl = https://localhost:5001

Staging environment:
  baseUrl = https://staging-products-api.azurewebsites.net

Production environment:
  baseUrl = https://products-api.azurewebsites.net

Switching the dropdown at the top-right of Postman from Dev to Staging instantly redirects every request in the collection, GetAll, GetById, Create, Update, Delete, without touching any of them individually.

Where Secrets Actually Belong

Never paste a real API key, token, or password directly into a request URL, header value, or body. Store it as a variable in an Environment instead, specifically marked as the secret type, not just a regular default variable.

Environment variables panel:

Variable          Type      Initial Value      Current Value
baseUrl           default   {{prod url}}       {{prod url}}
apiKey            secret    dots                dots

Secret-type variables are masked in the UI, shown as dots, excluded from Postman's own sync and export in plain text where possible, and meaningfully reduce the risk of a real key ending up visible in a screen recording, a shared workspace, or an accidentally committed export file.

Why this matters in practice: a request URL with a literal API key baked in gets saved into the collection permanently, anyone with access to that collection, a teammate, an accidental public share, now has that key too. A secret-type environment variable referenced by the apiKey variable keeps the actual value out of the request definition entirely.

Auth Headers, Handled Properly, Not Hand-Built

Postman's Authorization tab builds the correct header automatically for several common schemes, rather than requiring you to manually type the Authorization Bearer header into the Headers tab yourself.

Bearer Token: paste the token, ideally as a variable, and Postman adds the Authorization Bearer header automatically.
API Key: choose header or query param, provide the key name and value, Postman places it correctly either way.
Basic Auth: username and password, Postman handles the Base64 encoding automatically, you never touch it directly.
OAuth 2.0: Postman can run the actual token-fetching flow, Authorization Code, Client Credentials, and so on, directly inside the tool, then automatically attach the resulting token to the request.

Setting it once at the collection level: rather than configuring auth on every single request individually, set it once on the Collection itself, every request inside inherits it automatically, unless a specific request deliberately overrides it.

Building a Real Request

POST {{baseUrl}}/api/products

Headers:
  Content-Type: application/json

Body (raw, JSON):
{
  "name": "Wireless Mouse",
  "price": 24.99,
  "stockQuantity": 150
}

This maps directly to the CreateProductDto from the CRUD post, Postman sends this JSON body, ASP.NET Core model-binds it into that exact DTO, and the Required and Range validation attributes from that post apply before the action method body even runs.

Status Codes Worth Actually Checking

Checking only "did this return 200" misses most of what actually matters about an API's behavior.

200 OK is the default happy-path check, necessary but not sufficient on its own.
404 Not Found tests whether GetById correctly returns this for a genuinely missing product, matching the fix from the CRUD post, NotFound() instead of Ok(null).
400 Bad Request tests whether Create correctly rejects an empty Name or a negative Price, confirming the validation attributes are actually being enforced.
401 versus 403 are genuinely different meanings worth testing separately: 401 means you aren't authenticated at all, 403 means you are authenticated, but you don't have permission for this specific action.
201 Created tests whether Create returns this specifically, not 200, with a Location header pointing to the new resource, matching the fix from the CRUD post.
204 No Content tests whether Delete returns this specifically for a successful deletion with nothing further to return.

The Tests Tab: Real Assertions, Not Eyeballing

The Tests tab lets you write JavaScript assertions that run automatically every time the request is sent, checking the actual response against expected conditions, rather than a person visually scanning the JSON and hoping nothing looks wrong.

// Written in the Tests tab of the GetById request
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has expected fields", function () {
    const product = pm.response.json();
    pm.expect(product).to.have.property("id");
    pm.expect(product).to.have.property("name");
    pm.expect(product).to.have.property("price");
});

pm.test("Price is a positive number", function () {
    const product = pm.response.json();
    pm.expect(product.price).to.be.above(0);
});

// On the Create request specifically - testing the
// exact fix from the CRUD post
pm.test("Create returns 201, not 200", function () {
    pm.response.to.have.status(201);
});

pm.test("Response includes a Location header", function () {
    pm.response.to.have.header("Location");
});

Pre-request scripts set up state before the request fires. Postman also supports a Pre-request Script tab, running JavaScript before the request is sent, commonly used to generate a timestamp, compute a signature, or fetch a fresh token programmatically.

// Pre-request Script - saving a value from one response
// for use in a LATER request in the same collection
pm.test("Save the created product's id", function () {
    const response = pm.response.json();
    pm.collectionVariables.set("createdProductId", response.id);
});

// The NEXT request (GetById) can now reference
// {{createdProductId}} directly, chaining requests
// together using real data from a previous step

Running a Whole Collection at Once

The Collection Runner executes every request in a collection sequentially, running each request's tests automatically and producing a pass/fail summary, genuinely useful for confirming an entire API still behaves correctly after a change, not just one endpoint in isolation.

Collection Runner output (conceptual):

Products API - Run Summary
  GET All Products         PASS (2 tests)
  GET Product By Id        PASS (3 tests)
  POST Create Product      PASS (2 tests)
  PUT Update Product       PASS (1 test)
  DELETE Product           PASS (1 test)

  Total: 5 requests, 9 tests, 9 passed, 0 failed

This same collection can also run outside Postman's UI entirely, using Newman, Postman's command-line runner, making it possible to run this exact test suite inside a CI/CD pipeline, the same GitHub Actions workflow covered in an earlier post on this blog.

Closing the Loop: Importing From the Swagger Post

The earlier Swagger and OpenAPI post ended with exactly this workflow: with the app running, the OpenAPI spec is available at /swagger/v1/swagger.json. In Postman, choose Import and paste that URL, or upload the file, and Postman generates a complete collection automatically, every endpoint from ProductsController, correct verbs, correct routes, example bodies shaped from the DTOs. Everything covered in this post, environments, auth, tests, gets added on top of that auto-generated starting point, rather than building the whole collection by hand from nothing.

Problem Scenario and Solving Strategy

The problem: a team manually tests the Products API by clicking through Postman requests one at a time before every deployment, eyeballing each response. A regression, Create returning 200 instead of 201, went unnoticed for two weeks because nobody happened to check that specific detail during manual testing.

THE STRATEGY, STEP BY STEP:

Recognize this is a verification gap, not a testing effort gap - the team WAS testing, but manually, checking for "does it generally work" rather than specific, precise conditions
Import the API directly from its Swagger/OpenAPI spec (covered above) to get a complete, accurate starting collection instead of one built and maintained by hand
Add specific Tests tab assertions to every request - not just "status is 2xx" but the EXACT expected code (201 for Create, 204 for Delete, 404 for a missing GetById) - this is precisely the kind of narrow, easy-to-overlook detail manual eyeballing missed
Use the Collection Runner to execute the entire suite in one pass before each deployment, producing a clear pass/fail summary instead of relying on someone remembering to manually check every endpoint
Install Newman and add a step to the existing GitHub Actions CI/CD pipeline (covered in an earlier post) that runs this exact collection automatically on every push - turning "someone should really test this manually" into a check that happens whether anyone remembers to or not
The specific regression from the problem (201 vs 200) is now caught immediately, automatically, the next time it happens - rather than silently shipping for two weeks

Key Lessons

Environment variables let one collection work against dev, staging, and production without editing a single request, the variable changes, the requests don't.

Secrets belong in secret-type environment variables, never hardcoded into a request directly, the difference matters the moment a collection gets shared or exported.

The Authorization tab builds the correct header for Bearer, API Key, Basic Auth, and OAuth 2.0 automatically, and setting it once at the collection level avoids repeating it on every request.

Checking only for a 200 misses most of what an API actually promises, 404, 400, 401 versus 403, 201, and 204 each represent a genuinely different, separately-testable behavior.

The Tests tab turns "does this look right" into an actual, repeatable assertion, the same regression that manual eyeballing misses is exactly what a specific status-code test catches immediately.

A Postman collection isn't just a manual tool, via Newman, the exact same tests can run inside a CI/CD pipeline, automatically, on every push.

Summary

Postman's real value shows up once it moves past being a place to paste a URL and click Send. Collections keep requests organized and shareable, environment variables make the same collection work across every stage without editing anything, secret-type variables keep real credentials out of a shared file, the Authorization tab handles auth schemes correctly without manual header-building, and the Tests tab turns a visual check into a repeatable, automatable assertion. Combined with importing directly from a Swagger and OpenAPI spec and running the whole suite through Newman in CI/CD, Postman becomes a genuine verification tool, not just a way to manually poke at an API before hoping for the best.

Originally published on my blog: TechStack Blog

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Swagger and OpenAPI: The Docs That Write Themselves

Manohari Jayachandran — Thu, 03 Sep 2026 14:29:13 +0000

"Swagger" and "OpenAPI" get used interchangeably, and untangling that is actually the first useful thing to do here, one is a specification, the other is a tool that renders it. This post uses the Product API from an earlier CRUD post as the running example throughout, since the goal is showing exactly how documentation gets generated from code you've already written, not introducing a new domain to learn alongside a new concept.

What Swagger and OpenAPI Actually Are

OpenAPI is a specification, a structured JSON or YAML document that precisely describes an API: every endpoint, every parameter, every request body shape, every possible response. Swagger UI is one specific tool that takes that OpenAPI document and renders it as an interactive, browsable webpage, letting someone read the docs and actually try a request right from the browser. Swagger existed before OpenAPI became the open, vendor-neutral standard name for the specification format, which is exactly why people still say "Swagger" when they technically mean "OpenAPI."

Think of a restaurant's recipe card versus its printed menu. The recipe card in the kitchen is the precise, structured truth, exact ingredients, exact quantities, exact steps. The printed menu a customer reads is a different, friendlier presentation of that same underlying information, letting the customer browse and choose without ever seeing the recipe card itself. OpenAPI is the recipe card. Swagger UI is the printed menu.

What the Actual Generated Document Looks Like

Before going further, it helps to actually see one. This is a trimmed excerpt of the real JSON that AddSwaggerGen() would produce for the GetById endpoint used throughout this post, the file a browser fetches at /swagger/v1/swagger.json, and the exact same file Swagger UI reads to render its interactive page.

{
  "openapi": "3.0.1",
  "info": {
    "title": "Products API",
    "version": "v1"
  },
  "paths": {
    "/api/Products/{id}": {
      "get": {
        "tags": ["Products"],
        "operationId": "GetById",
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "required": true,
            "schema": { "type": "integer", "format": "int32" }
          }
        ],
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": { "$ref": "#/components/schemas/ProductDto" }
              }
            }
          },
          "404": {
            "description": "Not Found"
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "ProductDto": {
        "type": "object",
        "properties": {
          "id": { "type": "integer", "format": "int32" },
          "name": { "type": "string", "nullable": true },
          "price": { "type": "number", "format": "double" },
          "stockQuantity": { "type": "integer", "format": "int32" }
        }
      }
    }
  }
}

Every piece of this document maps directly to something already written in the code, "paths" comes from the controller's routes and HTTP verbs, the "200" and "404" entries come straight from the ProducesResponseType attributes covered next, and the ProductDto schema under "components" is a direct reflection of the DTO class itself, one property per line. This is genuinely the entire point of the post: nothing here was typed by hand into a documentation tool, it was all generated from code that already existed for other reasons.

How the Documentation Actually Gets Generated

The key thing to understand: you don't hand-write this specification. It's generated automatically by reflecting over your existing controllers, DTOs, and attributes, which is exactly why it can't silently drift out of date the way a manually maintained wiki page does.

// Program.cs - the two lines that turn this on
var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

// Visiting /swagger now shows a full interactive UI,
// built entirely from the ProductsController and DTOs
// already written for the CRUD post - nothing new to write

The Attributes That Shape the Generated Docs

By default, Swagger generates something reasonable but generic. Specific attributes let you control exactly what shows up, the response shapes, the possible status codes, and human-readable descriptions.

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id}")]
    [ProducesResponseType(typeof(ProductDto), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    public async Task<ActionResult<ProductDto>> GetById(int id)
    {
        var product = await _productService.GetByIdAsync(id);

        if (product == null)
            return NotFound();

        return Ok(product);
    }
}

These two ProducesResponseType attributes document both outcomes directly, a successful call returns a ProductDto shape with a 200, and a 404 is a documented, expected possibility, not a surprise. A frontend developer reading these generated docs never has to guess what a 404 from this specific endpoint means, or reverse-engineer it by triggering the error themselves.

// Adding a human-readable summary per endpoint
[HttpPost]
[SwaggerOperation(
    Summary = "Creates a new product",
    Description = "Validates the input and persists a new product record."
)]
public async Task<ActionResult<ProductDto>> Create(CreateProductDto dto)
{
    var created = await _productService.CreateAsync(dto);
    return CreatedAtAction(nameof(GetById), new { id = created.Id }, created);
}

// Requires the Swashbuckle.AspNetCore.Annotations NuGet package
// for [SwaggerOperation] specifically

Validation Attributes Show Up in the Docs Automatically

Here's a nice callback to the CRUD post: CreateProductDto's validation attributes weren't just added there to reject bad requests server-side, they do double duty, since Swagger reads them too and documents the actual constraints directly.

public class CreateProductDto
{
    [Required, MaxLength(200)]
    public string Name { get; set; }

    [Range(0.01, 1000000)]
    public decimal Price { get; set; }

    [Range(0, int.MaxValue)]
    public int StockQuantity { get; set; }
}

// In the generated Swagger UI, the Name field now shows
// as required with a 200-character max, and Price shows
// its valid range - all from attributes that were ALREADY
// there for a completely different reason (server-side
// validation), now also serving as documentation

Documenting Security Schemes

Without configuration, Swagger UI has no "Authorize" button and no way to actually test an authenticated endpoint from the browser. Adding a security scheme fixes this.

builder.Services.AddSwaggerGen(options =>
{
    options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Name = "Authorization",
        Type = SecuritySchemeType.Http,
        Scheme = "Bearer",
        BearerFormat = "JWT",
        In = ParameterLocation.Header,
        Description = "Enter a valid JWT token"
    });

    options.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            new string[] { }
        }
    });
});

// Swagger UI now shows an "Authorize" button - a caller
// can paste in a token once, and every subsequent
// "Try it out" request in the UI includes it automatically

Showing Multiple API Versions Side by Side

The same versioning concept from the APIM Part 2 post applies directly here, Swagger can present multiple documented versions of an API, letting a caller see exactly what changed between v1 and v2.

builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new OpenApiInfo { Title = "Products API", Version = "v1" });
    options.SwaggerDoc("v2", new OpenApiInfo { Title = "Products API", Version = "v2" });
});

app.UseSwaggerUI(options =>
{
    options.SwaggerEndpoint("/swagger/v1/swagger.json", "Products API v1");
    options.SwaggerEndpoint("/swagger/v2/swagger.json", "Products API v2");
});

// A dropdown in Swagger UI now lets a caller switch between
// documented versions directly, rather than needing separate
// documentation pages maintained independently

The Practical Payoff: Exporting Into Postman

A well-documented OpenAPI spec isn't just for humans reading a webpage, it's a structured document another tool can consume directly. Postman can import it and build a complete, ready-to-use collection automatically.

With the app running, the raw spec is available at /swagger/v1/swagger.json. In Postman, choose Import and paste that URL, or upload the downloaded JSON file directly. Postman then generates a full collection automatically, every endpoint from ProductsController, correct HTTP verbs, correct routes, even example request bodies shaped according to CreateProductDto's properties.

This is the direct bridge between writing good Swagger documentation and having a genuinely useful Postman collection, without manually building every request by hand.

Problem Scenario and Solving Strategy

The problem: a frontend team keeps asking what fields the Create Product endpoint actually expects, what a 404 means specifically on GetById, and what the exact shape of a successful response looks like. Answers currently live in a wiki page that was accurate three months ago and hasn't been touched since.

The strategy, step by step:

First, recognize this is a documentation freshness problem, not a communication problem, the wiki isn't wrong because nobody cares, it's wrong because nothing keeps it in sync with the actual code.
Second, enable Swagger generation if it isn't already, AddSwaggerGen and UseSwaggerUI, since this alone produces accurate docs for every route, verb, and DTO shape, generated directly from the real, currently-running code.
Third, add ProducesResponseType attributes to each action for every realistic outcome, 200, 404, 400, since this is what actually documents what a given status code means for this specific endpoint, not just that it's possible.
Fourth, confirm CreateProductDto's existing validation attributes are already doing double duty as documentation, no extra work needed here, just point the frontend team at the generated docs instead of the stale wiki page.
Finally, delete or clearly mark the old wiki page as deprecated, redirecting to the live Swagger UI, since the single source of truth is now the running application itself, not a separate document someone has to remember to update.

Key Lessons

OpenAPI is the specification, a structured document, while Swagger UI is one tool that renders it as a browsable page, the two terms get used interchangeably but describe different things.

The documentation is generated from code that already exists, controllers, DTOs, attributes, which is exactly why it can't silently go stale the way a manually maintained wiki page does.

ProducesResponseType documents both success and failure shapes explicitly, turning "this might return a 404" into a documented, expected part of the contract.

Validation attributes on a DTO do double duty, the same Required and Range attributes enforcing rules server-side also document those exact constraints automatically.

A security scheme definition is what actually makes the Authorize button in Swagger UI functional for testing authenticated endpoints directly in the browser.

The OpenAPI spec is machine-readable, not just human-readable, Postman and other tools can import it directly to generate a complete, accurate collection automatically.

What's Next

The next post covers Postman itself in depth, collections, environment variables, where secrets actually belong, auth headers, request building, status codes, and writing tests, including the exact import workflow referenced at the end of this post.

Summary

Swagger and OpenAPI solve a problem every API eventually has, documentation that's accurate the day it's written and wrong a month later. Generating the docs directly from the code, rather than writing them separately, is what actually keeps that from happening: a validation attribute, a response type, a security scheme, each one written once for a different practical reason, and each one automatically becoming part of the documentation too. The real payoff shows up at the boundary between tools, a well-documented API can hand its entire shape directly to something like Postman, turning "read the docs and manually build a request" into "import the spec and get a working collection immediately."

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=swagger-openapi-explained-with-example
More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals