DEV Community: Mirnes

Understanding the Lifecycle of a .NET Core Web API Request

Mirnes — Mon, 09 Jun 2025 00:00:00 +0000

When you send a request to a .NET Core Web API, it goes thru series of steps before a response is returned. Understanding this lifecycle is important in order to built what we need and how to use some of the prebuild functionalities. In this post, we’ll break down the main steps of the .NET Core Web API request lifecycle.

1. Application Startup

Before any request is handled, the application goes through the startup process:

Program.cs / Main Method : This is the entry point. It builds and runs the web host.
Startup.cs (if used):
- ConfigureServices: This method is used to register services in the Dependency Injection (DI) container.
- Configure: This sets up the HTTP request pipeline using middleware.

With .NET 6 and later, the startup logic is often consolidated into the Program.cs file using the minimal hosting model.

2. HTTP Request Pipeline (Middleware)

Once the application is running, every incoming HTTP request goes through the middleware pipeline. Middleware components can perform operations before and after the next component runs:

Built-in Middleware Examples :
- UseRouting – Matches the request to an endpoint.
- UseAuthentication – Handles authentication.
- UseAuthorization – Checks user permissions.
- UseEndpoints – Executes the matched endpoint (controller action, etc.).

Custom middleware can also be added for logging, request modification, etc.

3. Routing and Endpoint Matching

Routing determines which controller and action should handle the request:

Based on the request URL and HTTP method (GET, POST, etc.).
Routes can be attribute-based ([HttpGet("api/products")]) or convention-based (defined in MapControllers()).

4. Model Binding and Validation

Once the endpoint is matched:

Model Binding kicks in to map HTTP request data (query strings, headers, body) to method parameters and models.
Validation is performed using data annotations ([Required], [StringLength], etc.) or custom validators.

If validation fails, the framework can automatically return a 400 Bad Request.

5. Controller Action Execution

Now the actual controller method (action) is invoked. Here’s what happens:

Dependencies required by the controller or action method are injected.
The logic in the controller is executed.
It returns a result (e.g., Ok(), NotFound(), or a custom object).

6. Result Execution

The action result is processed and converted into an HTTP response:

This may involve serializing objects into JSON (typically using System.Text.Json or Newtonsoft.Json).
The framework sets the response headers and status code.

7. Middleware Response Processing

After the action result is generated, control returns back up through the middleware pipeline in reverse order. This gives middleware components the chance to:

Modify or inspect the response (e.g., add custom headers).
Log the outcome (status code, response time, etc.).
Handle exceptions globally (via custom exception-handling middleware).
Apply cross-cutting features like CORS, caching, and compression.

This is the final point where behavior can be influenced before the response goes back to the client.

8. Response Sent to Client

Finally, the HTTP response is sent back to the client. At this point, the request lifecycle is complete.

Conclusion

The .NET Core Web API request lifecycle is powerful and highly extensible. By understanding each step, you can design better APIs, implement robust logging and error handling, and create a maintainable architecture that scales well.

Happy coding!

Premature Optimization

Mirnes — Mon, 02 Jun 2025 06:32:01 +0000

In software development, performance matters, but chasing it too early can lead you into dangerous territory. This is the pitfall of premature optimization—a term that has become a cautionary mantra among developers. Coined famously by Donald Knuth, the phrase “premature optimization is the root of all evil” is not just a quip—it’s a hard-earned lesson from decades of building complex systems.

What Is Premature Optimization?

Premature optimization is the act of trying to make parts of a system faster or more efficient before there is a clear need or before you fully understand the system’s requirements and behavior. It often involves guessing at bottlenecks rather than measuring them, optimizing code paths that don’t impact the overall performance, or complicating designs in anticipation of hypothetical future needs.

Why It’s a Trap

1. Wasted Time and Effort

When you optimize too early, you risk spending hours or even days improving something that turns out to be irrelevant. You might optimize a loop that runs once per hour instead of a query that runs a thousand times per second. Without data, you’re solving the wrong problems.

2. Complexity Without Justification

Optimized code is often more complex and harder to read or maintain. If the performance gain isn’t needed, all you’re left with is unnecessary complexity—a debt you or your teammates will have to pay later.

3. Inhibits Flexibility

Over-optimized code is often not flexible. It’s tuned for a specific case and harder to refactor or extend. As project requirements evolve—which they always do—this premature rigidity can slow progress and reduce adaptability.

4. Violates YAGNI (You Aren’t Gonna Need It)

Premature optimization often assumes future needs—handling millions of users, processing terabytes of data, etc.—without current evidence. You end up designing for scale you may never reach, violating a key agile principle: build what you need when you need it.

When Optimization Does Matter

Of course, optimization has its place—after you’ve measured performance, identified real bottlenecks, and validated that improvements are necessary. This approach, known as profiling-first optimization, ensures that your efforts are focused where they will have real impact.

A few places where early attention to performance can be warranted include:

Low-level systems (like OS kernels or game engines)
High-frequency trading systems
Mobile or embedded systems with strict resource constraints

C- ode running in tight loops that process huge datasets

In these contexts, a deep understanding of performance may be built into the design from the beginning, but even then, measurements guide the process.

Best Practices to Avoid the Trap

Profile Before Optimizing: Use tools to measure real performance and identify hotspots.
Start Simple, Then Improve: Write clean, maintainable code first. Optimize only when needed.
Use Clear Benchmarks: Don’t optimize based on gut feelings. Set clear, measurable performance goals.
Isolate Critical Paths: Keep performance-critical code separate from general logic when needed.
Revisit with Data: As usage grows, revisit your code with new performance data and optimize accordingly.

Conclusion

Premature optimization is seductive. It feels like you’re being smart and proactive. But in reality, it often leads to wasted time, reduced code quality, and misallocated resources. In modern development, especially with powerful hardware and compilers, correctness, clarity, and maintainability should come first. Optimize when—and only when—the data tells you it’s necessary.

Write code that works. Make it clear. Then, if needed, make it fast.

Happy coding!

Design Patterns: Adapter

Mirnes — Mon, 26 May 2025 06:53:49 +0000

The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together. Rather than modifying existing code to fit a new system, the Adapter Pattern lets us wrap it with a new interface—acting as a bridge between mismatched parts of your application.

This approach is especially valuable when integrating legacy systems or third-party APIs that don’t follow your architecture or naming conventions.

When to Use the Adapter Pattern

You should consider using the Adapter Pattern when:

You need to integrate an existing class, but its interface doesn’t match what your code expects.
You’re modernizing or refactoring a system and want to avoid breaking changes.
You’re working with third-party libraries that can’t be modified.

Implementing the Prototype Pattern in C#

Lets imagine we are building an application that relies on a clean, simple interface for logging:

public interface ILogger
{
    void LogInfo(string message);
}

Now imagine you have a legacy logging class written years ago:

public class LegacyLogger
{
    public void WriteLogToFile(string severity, string message)
    {
        Console.WriteLine($"[{severity.ToUpper()}] {message} (written to file)");
    }
}

These two interfaces are incompatible. The client expects LogInfo(string), but the legacy class only supports WriteLogToFile(string, string).

Instead of modifying either interface, you can use the Adapter Pattern to resolve this mismatch.

Create the Adapter

public class LegacyLoggerAdapter : ILogger
{
    private readonly LegacyLogger _legacyLogger;

    public LegacyLoggerAdapter(LegacyLogger legacyLogger)
    {
        _legacyLogger = legacyLogger;
    }

    public void LogInfo(string message)
    {
        // Adapt method name and parameter structure
        _legacyLogger.WriteLogToFile("info", message);
    }
}

Here, LegacyLoggerAdapter translates the expected LogInfo method into the legacy class’s WriteLogToFile method.

Client

Now, our client code can use the ILogger interface without knowing anything about the legacy system:

class Program
{
    static void Main()
    {
        ILogger logger = new LegacyLoggerAdapter(new LegacyLogger());
        logger.LogInfo("Adapter pattern works!");
    }
}

The client gets the expected behavior, and the legacy system remains untouched.

Benefits

Decouples client code from implementation details
Avoids rewriting or breaking legacy systems
Supports Open/Closed Principle – open to extension, closed to modification
Makes third-party or legacy classes reusable in new contexts

When Not to Use It

When you can directly modify the original interface or class
When adding an adapter just introduces unnecessary complexity
If it’s used to hide bad design permanently instead of improving it over time

Conclusion

The Adapter Pattern is really useful when we need to make incompatible interfaces work together without modifying existing code. This pattern provides clean and maintanable solution in the cases when we need to deal with legacy systems, some external libraries or when we just trying to reuse old components in new ways.

Web API Versioning and Testing

Mirnes — Mon, 19 May 2025 06:22:10 +0000

In the previous post, we have paid attention on our project structure and organizing the code in multiple layers to achieve better readability and easier maintanence in the future. Now we can focus on long-term sustainability through versioning and testing.

In this final part of the series, we will:

Introduce API versioning so your app can evolve without breaking existing clients
Add unit tests to validate service and controller behavior

API Versioning?

Versioning helps your API evolve over time without breaking existing clients. Let’s enable it.

Step 1: Install Required Package

In the Sample.Api project, install:

dotnet add package Microsoft.AspNetCore.Mvc.Versioning

Step 2: Configure Versioning in Program.cs

In Program.cs, add the following:

    builder.Services.AddApiVersioning(options =>
    {
        options.AssumeDefaultVersionWhenUnspecified = true;
        options.DefaultApiVersion = new ApiVersion(1, 0);
        options.ReportApiVersions = true;
    });

This:

Defaults to version 1.0 when none is specified
Adds version info in response headers
Prepares your API to support multiple versions side-by-side

You can version your API using:

URL segments (/v1/controller)
Query string (?api-version=1.0)
Headers (e.g., api-version: 1.0)

We’ll use URL-based versioning in this example.

Step 3: Create a Versioned Controller

In Sample.Api/Controllers, decorate your controller like this:


[Route("api/v{version:apiVersion}/[controller]")]
[ApiVersion("1.0")]
[ApiController]
public class UserController : ControllerBase
{
....

That’s it—you’ve now added support for versioning via the URL.

Setting Up a Test Project

Now let’s set up unit testing using NUnit.

Step 1: Create a New Test Project

In the solution folder:

dotnet new nunit -n Sample.Api.Tests

Then add project references:

dotnet add Sample.Api.Tests reference Sample.Services
dotnet add Sample.Api.Tests reference Sample.Repositories
dotnet add Sample.Api.Tests reference Sample.DTO
dotnet add Sample.Api.Tests reference Sample.Entities

And install these packages:

dotnet add Sample.Api.Tests package Moq
dotnet add Sample.Api.Tests package Microsoft.AspNetCore.Mvc

Next, we can organize our tests in different folders, like /Services, /Repositories, /Controllers

Step 2: Writing Unit Tests for Services

Now, for the showing purpose, we can test UserService by mocking UserRepository:

[TestFixture]
public class UserTests
{
    [Test]
    public void GetUserByUsername_ReturnsDataFromRepo()
    {
        var mockRepo = new Mock<IUserRepository>();
        mockRepo.Setup(r => r.GetUser("Test")).Returns(new User()
        {
            Id = 1,
            Email = "test mail",
            Username = "Test",
        });

        var service = new UserService(mockRepo.Object);
        var user = service.GetUser("Test");

        Assert.That(user.Email, Is.EqualTo("test mail"));
    }
}

Here, we have shown one mocking example and how to isolate our service testing from depencency on repository. Similar can be done with controllers as well. For more details on testing and mocking, you can take a look at some of the previous posts for unit testing and mocking.

Summary

With versioning and testing in place, your API is now ready for real-world use:

Versioning allows the API to grow without breaking existing clients
Unit tests help you catch regressions early and keep logic robust

This wraps up our step-by-step guide to building a clean, testable, and production-ready .NET 9 Web API using best practices. Entire code can be found at my github repository.

Thanks for following the series!

Happy coding!

Web API Architecture: Services and Repositories

Mirnes — Mon, 12 May 2025 07:38:44 +0000

In the previous post, we added global error handling and logging using NLog. Now that we’ve made our API more resilient, it’s time to go forwards with cleaning up the architecture and separate concerns.

In this post, we’ll cover:

Introduce a clean project structure
Create Service and Repository layers
Register dependencies with Dependency Injection
Hook everything up in a simple API endpoint

This sets the foundation for building a maintainable and testable API going forward.

Why Clean Architecture?

A clean arhitecture helps us keeping business logic separate from infrastructure layer and make our project easier to test and extend and, in the end, it improves readability and maintanability over time.

Proposed Project Structure

We’ll split the solution into multiple class libraries to keep things modular and clean:

Sample.Api contains API-specific setup like controllers and middleware.
Sample.Services includes business logic, independent of controllers or data sources.
Sample.Repositories handles communication with the database.
Sample.Entities contains models that map directly to your database schema.
Sample.DTO defines what’s exposed via API—keeping entities encapsulated.

Each layer references only what it needs. For example:

Sample.Services references Sample.Repositories, Sample.DTO, Sample.Entities
Sample.Repositories references Sample.Entities
Sample.Api references Sample.Services, Sample.Repositories and Sample.DTO

Lets Create Migration With Some Test Data

Update your Migrations with:

    [Migration(20250503001)]
    public class Mig20250503001_UsersTestData : Migration
    {
        public override void Down()
        {
            throw new NotImplementedException();
        }

        public override void Up()
        {
            Insert.IntoTable("Users").Row(new
            {
                Username = "john.doe",
                Email = "john.doe@email.com"
            });

        }
    }
}

Repository

In the repository project we need to add SqlKata library. More info about SqlKata can be found in one of my earlier post

using Sample.Entities;
using SqlKata.Execution;

namespace Sample.Repositories
{
    public interface IUserRepository
    {
        int InsertNewUser(User user);
        User GetUser(int userId);
        User GetUser(string username);
    }
    public class UserRepository : IUserRepository
    {
        private readonly QueryFactory _db;
        private const string TableName = "Users";

        public UserRepository(QueryFactory db)
        {
            _db = db;
        }

        public int InsertNewUser(User user)
        {
            return _db.Query(TableName).InsertGetId<int>(user);
        }

        public User GetUser(int userId)
        {
            return _db.Query(TableName).Where(nameof(User.Id), userId).Get<User>().Single();
        }

        public User GetUser(string username)
        {
            return _db.Query(TableName).Where(nameof(User.Username), username).Get<User>().Single();

        }
    }
}

Service

namespace Sample.Services
{
    public interface IUserService
    {
        int InsertNewUser(UserDTO user);
        UserDTO GetUser(string username);
    }
    public class UserService : IUserService
    {
        private readonly IUserRepository _repository;
        public UserService(IUserRepository repository)
        {
            _repository = repository;
        }

        public UserDTO GetUser(string username)
        {
            var entity = _repository.GetUser(username);
            return new UserDTO()
            {
                Username = entity.Username,
                Email = entity.Email
            };
        }

        public int InsertNewUser(UserDTO user)
        {
            var entity = new User()
            {
                Username = user.Username,
                Email = user.Email
            };
            return _repository.InsertNewUser(entity); }
    }
}

Here is just a simple implementation given, but the base idea is for service classes to manage interaction between Repositories and Api Controllers and do all the things in between about mapping data and additional business logic.

Register all in `Program.cs`


....

builder.Services.AddScoped(provider =>
{
    var connection = new SqlConnection(connectionString);

    var compiler = new SqlServerCompiler();

    return new QueryFactory(connection, compiler);
});

builder.Services.AddScoped<IUserRepository, UserRepository>();

builder.Services.AddScoped<IUserService, UserService>();

....

Controller

namespace Sample.Api.Controllers
{
    [Route("[controller]")]
    [ApiController]
    public class UserController : ControllerBase
    {

        private readonly IUserService _service;
        public UserController(IUserService service)
        {
            _service = service;
        }

        public UserDTO GetUserByUsername(string username)
        {
            return _service.GetUser(username);
        }
    }
}

Summary

With the new project structure in place:

Business logic lives in the service layer
Data access is cleanly separated in a repository
Models are split into entities and DTOs
The API is minimal and focused on routing and HTTP interaction

This is a scalable foundation that makes future growth and testing straightforward.

Coming Up Next…

In Part 4, we’ll focus more on testing and API versioning.

Stay tuned!

Web API Exception Handling and Logging

Mirnes — Mon, 05 May 2025 10:20:07 +0000

In the previous post, we set up a basic .NET 9 Web API project. Now it’s time to take things further by adding global error handling and logging to make our API more robust.

In this post, we’ll cover:

How to implement global error handling with middleware
Setting up NLog to log errors to both files and a database table
Creating a migration for the log table in the database

Why Global Error Handling?

Handling errors in one centralized place makes your API easier to maintain and more consistent. Instead of repeating error-catching logic in every controller, you can handle unexpected issues in a single middleware.

This approach allows you to return uniform error responses and capture useful logs automatically when something goes wrong.

Creating Global Error Handling Middleware

Create a Middleware folder in your project and add a file called ExceptionHandlingMiddleware.cs:

using Microsoft.AspNetCore.Http;
using System;
using System.Net;
using System.Threading.Tasks;

public class ExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(httpContext, ex);
        }
    }

    private Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
        context.Response.ContentType = "application/json";
        var result = new { message = "An unexpected error occurred. Please try again later." };
        return context.Response.WriteAsJsonAsync(result);
    }
}

Registering the Middleware

Update your Program.cs to use this middleware:

using FluentMigrator.Runner;
using Sample.Api.Middleware;
using Sample.Migrations.Migrations;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();

// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

var app = builder.Build();

app.UseMiddleware<ExceptionHandlingMiddleware>();

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

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

Setting Up NLog in .NET 9

Install the NLog packages

dotnet add package NLog.Web.AspNetCore
dotnet add package NLog.Database

Add a `nlog` config to `appsettings.json` file

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=SampleDb;Trusted_Connection=True;TrustServerCertificate=True"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    },
    "NLog": {
      "IncludeScopes": true,
      "RemoveLoggerFactoryFilter": true
    }
  },
  "AllowedHosts": "*",
  "NLog": {
    "autoReload": true,
    "throwConfigExceptions": true,
    "internalLogLevel": "Info",
    "internalLogFile": "${basedir}/internal-nlog.txt",
    "extensions": [
      { "assembly": "NLog.Extensions.Logging" },
      { "assembly": "NLog.Web.AspNetCore" },
      { "assembly": "NLog.Database" }
    ],
    "variables": {
      "var_logdir": "c:/temp"
    },
    "time": {
      "type": "AccurateUTC"
    },
    "targetDefaultWrapper": {
      "type": "AsyncWrapper",
      "overflowAction": "Block"
    },
    "targets": {
      "all-file": {
        "type": "File",
        "fileName": "${var_logdir}/nlog-all-${shortdate}.log",
        "layout": {
          "type": "JsonLayout",
          "Attributes": [
            {
              "name": "timestamp",
              "layout": "${date:format=o}"
            },
            {
              "name": "level",
              "layout": "${level}"
            },
            {
              "name": "logger",
              "layout": "${logger}"
            },
            {
              "name": "message",
              "layout": "${message:raw=true}"
            },
            {
              "name": "properties",
              "encode": false,
              "layout": {
                "type": "JsonLayout",
                "includeallproperties": "true"
              }
            }
          ]
        }
      },
      "database": {
        "type": "Database",
        "dbProvider": "Microsoft.Data.SqlClient.SqlConnection,Microsoft.Data.SqlClient",
        "connectionString": "Data Source=localhost;Initial Catalog=SampleDb;Trusted_Connection=True;TrustServerCertificate=True",
        "keepConnection": "true",
        "commandText": "insert into dbo.[Logs] (TimeStamp,Level,Message,Logger,Exception) values (@Timestamp, @Level, @Message, @Logger, @Exception);",
        "parameters": [
          {
            "name": "@Timestamp",
            "layout": "${date:format=o}",
            "dbType": "DbType.DateTime"
          },
          {
            "name": "@Level",
            "layout": "${level}"
          },
          {
            "name": "@Message",
            "layout": "${message}"
          },
          {
            "name": "@Logger",
            "layout": "${logger}"
          },
          {
            "name": "@Exception",
            "layout": "${exception:format=toString}"
          }
        ]
      }
    },
    "rules": [
      {
        "logger": "*",
        "minLevel": "Trace",
        "writeTo": "all-file"
      },
      {
        "logger": "*",
        "minLevel": "Error",
        "writeTo": "database"
      }
    ]
  }
}

Load NLog config in `Program.cs`


....

LogManager.Setup().LoadConfigurationFromAppSettings();

....

Add logger to `ExceptionHandlingMiddleware.cs`

public class ExceptionHandlingMiddleware
{
    ...

    private readonly Logger _logger = LogManager.GetCurrentClassLogger();

    ...
    public async Task InvokeAsync(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext);
        }
        catch (Exception ex)
        {
            _logger.Error(ex, ex.Message);
            await HandleExceptionAsync(httpContext, ex);
        }
    }
    ...
}

Creating the `Logs` Table with FluentMigrator

Let’s create a migration to add a Logs table to our database where NLog can store log entries.

using FluentMigrator;

namespace Sample.Migrations.Migrations
{
    [Migration(20250426001)]
    public class Mig20250426001_CreateLogsTable: Migration
    {
        public override void Up()
        {
            Create.Table("Logs")
                .WithColumn("Id").AsInt32().PrimaryKey().Identity()
                .WithColumn("TimeStamp").AsDateTime().NotNullable()
                .WithColumn("Level").AsString(50).NotNullable()
                .WithColumn("Logger").AsString(100).NotNullable()
                .WithColumn("Message").AsString(1000).NotNullable()
                .WithColumn("Exception").AsString(100).Nullable();
        }

        public override void Down()
        {
            Delete.Table("Logs");
        }
    }
}

Coming Up Next…

In Part 3, we’ll introduce a project structure with service and repository layers, and use dependency injection to organize your business logic.

Stay tuned!

Web API Project Setup and Migrations

Mirnes — Mon, 28 Apr 2025 10:16:19 +0000

Welcome to the first post in the “.NET Core Web API – Step-by-Step Best Practices” series. In this series, we’ll walk through building a modern, clean, and maintainable Web API using .NET 9. Each post will focus on a specific aspect—from project setup and architecture to testing, migrations, and deployment.

In This Post

We’ll cover:

Creating a new .NET 9 Web API project
Understanding the default project structure
Setting up FluentMigrator
Writing and running your first database migration

Step 1: Create the API Project

Start by creating a new Web API project using the .NET CLI:

dotnet new webapi -n Sample.Api --use-controllers

Understanding the Project Structure

After creating the project, you’ll see something like this:

Sample.Api/
├── Controllers/
│ └── WeatherForecastController.cs
├── Program.cs
├── appsettings.json
└── Sample.Api.csproj
.
.
.

`Program.cs`

This is the entry point of the app. It sets up services and configures the request pipeline. Here’s the full code of Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();

// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

var app = builder.Build();

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

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

Let’s break it down:

var builder = WebApplication.CreateBuilder(args); initializes the app’s builder, where you configure services and settings. The args parameter allows command-line arguments to be passed in.
builder.Services.AddControllers(); adds support for controllers, enabling your Web API to handle incoming HTTP requests.
builder.Services.AddOpenApi();, this is simplified in dotnet 9, and used instead of builder.Services.AddEndpointsApiExplorer(); and builder.Services.AddSwaggerGen();. It adds Swagger support for generating API documentation. This is useful for testing and exploring your API.
var app = builder.Build(); builds the WebApplication object, finalizing the app configuration and preparing it for running.
if (app.Environment.IsDevelopment()) { app.MapOpenApi(); // same as app.UseSwagger(); app.UseSwaggerUI(); } enables Swagger UI for development environments, making it easy to explore and test the API.
app.UseHttpsRedirection(); redirects all http requests to https
app.UseAuthorization(); adds middleware for handling authorization, which is necessary if your API needs to control access to certain routes.
app.MapControllers(); maps the controller routes to the HTTP request pipeline, allowing the API to handle requests.
app.Run(); starts the app and begins listening for incoming requests.

`appsettings.json`

This file is used for configuration—stuff like connection strings, logging, and environment-specific settings:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=SampleDb;Trusted_Connection=True;TrustServerCertificate=True"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

`Controllers/`

This folder holds your API endpoints. It’s where we’ll define controllers.

Step 2: Create a Separate Migrations Project

We want to keep our code modular and focused , so we’ll separate database migration logic from our main Web API project and create a dedicated class library just for migrations.

Why put migrations in a separate class library?

Here are a couple of reasons:

Separation of concerns : Your Web API project should focus on handling HTTP requests and responses—not managing database schema. Keeping migrations in their own project ensures the API stays lean and focused.
Cleaner dependencies : The migration project will only reference what’s needed for database changes.
Better organization : As your project grows, having migrations away from API, in a dedicated project, keeps things easier to manage and navigate.

Create the migration library

Let’s create the class library:

dotnet new classlib -n Sample.Migrations

Then install the FluentMigrator packages:

cd Sample.Migrations
dotnet add package FluentMigrator.Runner
dotnet add package FluentMigrator.Extensions.SqlServer

Now go back to your Web API project and link it to the migration library:

cd ../Sample.Api
dotnet add reference ../Sample.Migrations/Sample.Migrations.csproj

At this point, your solution structure looks like this:

Sample.Api/
├── Program.cs
├── appsettings.json
└── ...

Sample.Migrations/
└── Sample.Migrations.csproj

Step 3: Create Your First Migration

Inside the Sample.Migrations project, create folder Migrations/, and add this migration class:

using FluentMigrator;

namespace Sample.Migrations.Migrations;

[Migration(20250421001)]
public class InitialMigration : Migration
{
    public override void Up()
    {
        Create.Table("Users")
            .WithColumn("Id").AsInt32().PrimaryKey().Identity()
            .WithColumn("Username").AsString(100).NotNullable()
            .WithColumn("Email").AsString(200).NotNullable();
    }

    public override void Down()
    {
        Delete.Table("Users");
    }
}

About the `[Migration]` attribute

The number you pass into the [Migration(...)] attribute is a unique ID for the migration. A common and helpful naming convention is to use a timestamp format, followed by a sequence number. Example:

YYYYMMDD + sequence

So in our case:

20250421001

That means this is the first migration created on April 21, 2025. This format is nice because:

Migrations are naturally sorted in order
You can tell when each migration was created at a glance
It avoids name conflicts even if multiple migrations are added in the same day

Step 4: Configure FluentMigrator in the Web API

Back in Program.cs of Sample.Api, register FluentMigrator and point it to the Sample.Migrations assembly:

using FluentMigrator.Runner;
using Sample.Migrations.Migrations;

var builder = WebApplication.CreateBuilder(args);

// Add services
builder.Services.AddControllers();

builder.Services.AddOpenApi();

// Configure FluentMigrator using the separate migrations project
builder.Services.AddFluentMigratorCore()
    .ConfigureRunner(rb => rb
        .AddSqlServer()
        .WithGlobalConnectionString(
            builder.Configuration.GetConnectionString("DefaultConnection")!)
        .ScanIn(typeof(InitialMigration).Assembly).For.Migrations())
    .AddLogging(lb => lb.AddFluentMigratorConsole());

var app = builder.Build();

// Apply pending migrations on startup
using (var scope = app.Services.CreateScope())
{
    var runner = scope.ServiceProvider.GetRequiredService<IMigrationRunner>();
    runner.MigrateUp();
}

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

app.UseHttpsRedirection();

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

Coming Up Next…

In Part 2, we’ll dive into global error handling and logging. We’ll cover:

Setting up custom error handling middleware
Implementing logging for your API using NLog
How to effectively capture and log error details

Thanks for reading! See you in Part 2!

Understanding State Machines with a Practical Example in C#

Mirnes — Mon, 21 Apr 2025 05:12:07 +0000

State machines might sound like a complex topic, but at their core, they’re just a way to manage different states in a system and control how things transition from one state to another.

In this post, we’ll break down what state machines are, why they’re useful, and how to implement one in C# using a straightforward approach. We’ll also walk through a real-world example to see them in action.

What is a State Machine?

A state machine is a pattern used to control the flow of a system by defining possible states and the rules that determine how transitions between those states happen. It consists of:

States : Different conditions or modes the system can be in.
Transitions : Rules that define how the system moves from one state to another.
Events : Triggers that cause state transitions.
Actions : Operations performed when entering, exiting, or staying in a state.

Why Use a State Machine?

State machines provide several benefits when managing workflows:

Improved Readability : Helps organize complex logic in an understandable way.
Encapsulation of State Logic : Keeps state-specific behavior separate from other business logic.
Predictability and Maintainability : Makes it easier to track and debug state changes.
Flexibility : New states and transitions can be added without major changes.

Implementing a State Machine in C#

Let’s implement a simple state machine using a dictionary to manage state transitions.

Use Case: Order Processing System

Imagine you’re building an e-commerce application that handles order statuses. An order can go through several states before completion.

States and Transitions

States : PendingPayment, Processing, Shipped, Delivered, Cancelled
Events :
- Pay (moves from PendingPayment to Processing)
- Ship (moves from Processing to Shipped)
- Deliver (moves from Shipped to Delivered)
- Cancel (moves from PendingPayment to Cancelled or from Processing to Cancelled)

C# Implementation

State Machine Logic :

using System;
using System.Collections.Generic;

class OrderStateMachine
{
    public enum OrderState { PendingPayment, Processing, Shipped, Delivered, Cancelled }
    public enum OrderTrigger { Pay, Ship, Deliver, Cancel }

    private Dictionary<(OrderState, OrderTrigger), OrderState> _stateTransitions;
    public OrderState CurrentState { get; private set; }

    public OrderStateMachine()
    {
        CurrentState = OrderState.PendingPayment;
        _stateTransitions = new Dictionary<(OrderState, OrderTrigger), OrderState>
        {
            { (OrderState.PendingPayment, OrderTrigger.Pay), OrderState.Processing },
            { (OrderState.PendingPayment, OrderTrigger.Cancel), OrderState.Cancelled },
            { (OrderState.Processing, OrderTrigger.Ship), OrderState.Shipped },
            { (OrderState.Processing, OrderTrigger.Cancel), OrderState.Cancelled },
            { (OrderState.Shipped, OrderTrigger.Deliver), OrderState.Delivered }
        };
    }

    public void ProcessTransition(OrderTrigger trigger)
    {
        if (_stateTransitions.TryGetValue((CurrentState, trigger), out OrderState newState))
        {
            Console.WriteLine($"Moving from {CurrentState} to {newState} due to {trigger}");
            CurrentState = newState;
        }
        else
        {
            Console.WriteLine($"Invalid transition: {CurrentState} cannot handle {trigger}");
        }
    }
}

Client :

class Program
{
    static void Main()
    {
        var orderStateMachine = new OrderStateMachine();
        Console.WriteLine($"Initial state: {orderStateMachine.CurrentState}");

        // Simulating order processing
        orderStateMachine.ProcessTransition(OrderStateMachine.OrderTrigger.Pay);
        orderStateMachine.ProcessTransition(OrderStateMachine.OrderTrigger.Ship);
        orderStateMachine.ProcessTransition(OrderStateMachine.OrderTrigger.Deliver);
    }
}

How It Works

The OrderStateMachine class encapsulates state logic, making the main program cleaner.
The CurrentState property tracks the current order state.
The _stateTransitions dictionary holds valid state transitions.
The ProcessTransition() method checks for valid transitions and updates the state.
The Main method initializes the state machine and processes transitions.

Conclusion

State machines are an excellent way to manage complex workflows in a clean, predictable manner. Using a simple dictionary in C#, we can build a flexible and maintainable system to handle order states. By encapsulating state logic in a class, we make our code cleaner, more modular, and easier to maintain. Whether you're working on UI workflows, business processes, or game logic, state machines provide a structured approach to managing state transitions effectively.

Design Patterns: Prototype

Mirnes — Mon, 14 Apr 2025 06:19:31 +0000

In software development, there are scenarios where creating multiple objects with similar attributes and configurations is necessary. Instead of constructing each object from scratch, a more efficient approach is to duplicate an existing instance. This is precisely what the Prototype Design Pattern facilitates.

What is the Prototype Pattern?

The Prototype pattern is a creational design pattern that focuses on cloning objects. Rather than instantiating new objects directly, this pattern allows for the creation of copies of existing instances. This can be particularly beneficial when object creation is expensive or complex.

Benefits of Using the Prototype Pattern

Improved Performance – If object creation involves expensive operations such as database queries or intensive computations, cloning can optimize performance.
Simplified Object Initialization – When an object requires extensive setup, cloning eliminates redundant initialization steps.
Dynamic Object Modifications – Prototypes can be modified at runtime, enabling flexible object creation.

Implementing the Prototype Pattern in C#

General Approach

A common way to implement the Prototype pattern is by defining a prototype interface that declares a cloning method. This ensures that all implementing classes provide their own cloning logic, allowing for consistent object duplication.

public interface IPrototype<T>
{
    T Clone();
}

Using a generic interface allows different types to define their own cloning mechanisms while ensuring type safety. In C#, there is already provided ICloneable interface which has the same intention.

Step 1: Implement a Concrete Class

Consider a Car class that implements ICloneable:

public class Car : ICloneable
{
    public string Model { get; set; }
    public string Color { get; set; }

    public Car(string model, string color)
    {
        Model = model;
        Color = color;
    }

    public object Clone()
    {
        return new Car(this.Model, this.Color);
    }
}

Step 2: Clone Objects

Now, we can create and modify cloned objects efficiently:

Car car1 = new Car("Tesla Model S", "Red");
Car car2 = (Car)car1.Clone();
car2.Color = "Blue";

Console.WriteLine($"Car1: {car1.Model}, {car1.Color}"); // Output: Car1: Tesla Model S, Red
Console.WriteLine($"Car2: {car2.Model}, {car2.Color}"); // Output: Car2: Tesla Model S, Blue

The car2 instance is cloned from car1, and its color is modified independently.

When to Use the Prototype Pattern

This pattern is particularly useful when:

Object creation is resource-intensive, and cloning provides a more efficient alternative.
There is a need to generate multiple similar objects dynamically.
Avoiding complex initialization logic enhances maintainability.

When Not to Use the Prototype Pattern

If object creation is straightforward, cloning may introduce unnecessary complexity.
If an object depends on external resources that should not be duplicated, such as database connections.

Conclusion

The Prototype Design Pattern is a practical solution for optimizing object creation in C#. By leveraging the ICloneable interface, we can efficiently create and modify objects while maintaining code simplicity and efficiency.

Code Review Best Practices

Mirnes — Mon, 07 Apr 2025 13:01:58 +0000

Code reviews are a crucial part of writing great software. They help maintain code quality, catch bugs early, and improve collaboration. But if done poorly, they can be frustrating, time-consuming, and even demotivating. So, how do you make your code reviews effective and useful?

What to Do?

1. Prioritize Code Quality and Maintainability

Make sure the code follows best practices and style guidelines.
Check for ways to improve performance and efficiency.
Ensure the code is easy to read and well-structured.

2. Give Constructive, Respectful Feedback

Focus on helping, not just pointing out mistakes.
Offer suggestions rather than just criticism.
Highlight things that were done well, not just areas that need improvement.

3. Ensure the Code is Properly Tested

Look for unit tests and integration tests where needed.
Check for edge cases and possible failure points.
Make sure tests actually pass before approving the PR.

4. Look Out for Security and Performance Issues

Watch for common security risks like SQL injection, XSS, and hardcoded secrets.
Keep an eye on database queries and API calls for efficiency.
Avoid unnecessary complexity that could slow things down.

5. Make Sure the Code Solves the Right Problem

Confirm that the implementation matches the requirements.
If there are UI changes, make sure they align with design specs.
Double-check that the solution is practical and efficient.

6. Encourage Small, Manageable PRs

Reviewing smaller pull requests is faster and more effective.
Give feedback promptly so you don’t block progress.
Encourage breaking big changes into smaller, focused updates.

7. Use Automation to Catch Basic Issues

Rely on linters and static analysis tools for style enforcement.
Let CI/CD pipelines handle basic testing and code coverage checks.
Automate formatting so you don’t have to waste time on minor faults.

What Not to Do?

1. Don’t Make It Personal

Critique the code, not the developer.
Use respectful, inclusive language.
Remember that everyone, no matter how experienced, makes mistakes.

2. Don’t Rush Through The Review

Take the time to understand the code before commenting.
Avoid approvals without actually checking the details.
Make sure your feedback is clear and actionable.

3. Don’t Hold Up Reviews For Too Long

Give feedback as soon as possible to keep things moving.
If you’re busy, let the team know so they can adjust expectations.

4. Don’t Expect Perfection Right Away

It’s okay if the first draft isn’t perfect—focus on incremental improvements.
Balance high standards with realistic expectations.

5. Don’t Overcomplicate Things

Keep suggestions practical and easy to follow.
Avoid unnecessary refactoring unless it truly improves the code.

Final Thoughts

Code reviews should be a positive, collaborative process. They’re not just about finding mistakes—they’re about making the code better and helping each other grow as developers. Keep feedback constructive, focus on maintainability, and use automation where you can to make the process smoother. Most importantly, remember that you are all on the same team, and that you are improving your product together.

Happy coding and happy reviewing!

TDD and Mocking

Mirnes — Tue, 01 Apr 2025 07:38:58 +0000

In the last post we have discussed core principles of unit testing and TDD. In this post, we’ll walk through a simple example of how to use Moq as mocking framework and Dependency Injection with NUnit in the context of Test-Driven Development (TDD) in C#. This combination allows for clean, maintainable tests by mocking dependencies and focusing on the behavior of the system under test.

Imagine we have an application where we process payments through a PaymentService. This service depends on an external IPaymentGateway interface to make the actual payment.

Let’s break this down step by step.

Step 1: Write the Test First (Before Code)

We want to test the PaymentService, which depends on the IPaymentGateway. Our first test will focus on making sure the PaymentService behaves correctly when making a valid payment.

Here's the test code:

using Moq;
using NUnit.Framework;

[TestFixture]
public class PaymentServiceTests
{
    private Mock<IPaymentGateway> _mockPaymentGateway;
    private PaymentService _paymentService;

    [SetUp]
    public void Setup()
    {
        // Create the mock object
        _mockPaymentGateway = new Mock<IPaymentGateway>();

        // Inject the mock into the PaymentService
        _paymentService = new PaymentService(_mockPaymentGateway.Object);
    }

    [Test]
    public void MakePayment_WhenAmountIsValid_ShouldReturnTrue()
    {
        // Arrange
        var amount = 100m; // Valid amount
        _mockPaymentGateway.Setup(gateway => gateway.ProcessPayment(amount)).Returns(true);

        // Act
        var result = _paymentService.MakePayment(amount);

        // Assert
        Assert.IsTrue(result);
    }
}

Step 2: Run the Test (It Will Fail)

Since we haven’t implemented the PaymentService or the IPaymentGateway yet, running the test will result in a failure. The error message would indicate that the PaymentService and IPaymentGateway don’t exist yet.

Now we need to implement the minimal code to make this test pass.

Step 3: Write the Code to Pass the Test

We need to create the PaymentService and IPaymentGateway interface so that the test can run successfully.

Here’s the implementation of the IPaymentGateway interface and the PaymentService class:

public interface IPaymentGateway
{
    bool ProcessPayment(decimal amount);
}public class PaymentService
{
    private readonly IPaymentGateway _paymentGateway;

    public PaymentService(IPaymentGateway paymentGateway)
    {
        _paymentGateway = paymentGateway;
    }

    public bool MakePayment(decimal amount)
    {
        // Business logic for validating amount (e.g., check if it's positive)
        if (amount <= 0)
        {
            return false;
        }

        // Process the payment through the gateway
        return _paymentGateway.ProcessPayment(amount);
    }
}

Step 4: Run the Test Again (It Should Pass)

Now that we've implemented the PaymentService and IPaymentGateway, we can run the test again.

If everything is set up correctly, this time the test should pass. The output should indicate that the MakePayment method of the PaymentService is functioning as expected, returning true when a valid amount is passed and the gateway returns true.

Step 5: Write Another Test (The Test-Grow Approach)

The next step in TDD is to write another test for a different scenario. In this case, we will test when an invalid payment amount is passed (e.g., a negative or zero amount). Let's write this test.

Here’s the next test:

[Test]
public void MakePayment_WhenAmountIsInvalid_ShouldReturnFalse()
{
    // Arrange
    var amount = -50m; // Invalid amount
    _mockPaymentGateway.Setup(gateway => gateway.ProcessPayment(It.IsAny<decimal>())).Returns(false);

    // Act
    var result = _paymentService.MakePayment(amount);

    // Assert
    Assert.IsFalse(result);
}

Step 6: Refactor the Code if Needed

Now, we have a test for the invalid case, and we should implement any additional logic if necessary to make this test pass. In our current code, the logic already returns false if the amount is less than or equal to 0. This means the code is already correct, and we don't need to change anything.

Conclusion

This example demonstrates how to apply Test-Driven Development in C# with NUnit, Moq, and Dependency Injection. By mocking dependencies, you can easily test the behavior of your services without relying on the real implementations, making your tests faster and more reliable. Dependency injection ensures that dependencies are easily replaceable, promoting clean, maintainable code.

Unit Testing and Test-Driven Development (TDD) in C#

Mirnes — Sun, 23 Mar 2025 11:00:00 +0000

Writing code without unit tests can be risky—you might not realize issues until it’s too late. Unit testing helps make sure your code actually does what it's supposed to. In this post, we’ll break down unit testing in C# using NUnit and explore how Test-Driven Development (TDD) can make your life easier.

What’s Unit Testing Anyway?

Unit testing is all about testing small, isolated chunks of your code to make sure they work correctly. Instead of waiting until the whole application is built and then scrambling to fix bugs, unit tests let you catch issues early. In C#, we typically use frameworks like NUnit , xUnit , or MSTest to write and run these tests.

Why Should You Care About Unit Testing?

Find Bugs Early: Fixing issues sooner rather than later saves time (and headaches).
Make Your Code More Maintainable: Well-tested code is easier to update and improve.
Write Better Code: Writing testable code forces you to structure it well.
Acts as Documentation: Your tests describe what your code is supposed to do.

What is Test-Driven Development (TDD)?

TDD is a mindset shift where you write your tests before you write the actual implementation. It follows a simple cycle:

Write a test that fails (because the feature doesn’t exist yet).
Write just enough code to make the test pass.
Refactor and clean up the code while keeping the test green.

Why Bother with TDD?

Guarantees better test coverage.
Helps you write only the code you actually need.
Saves you time debugging later.
Makes your code modular and easy to change.
Every test case serves as a description of a use case, making tests a form of living documentation for your code.
Encourages better code structure by promoting loose coupling, dependency injection, and composition-based design patterns.

Step-by-Step Guide: TDD with NUnit in C#

Step 1: Setting Up NUnit in Your Project

Getting started is easy:

Create a new NUnit Test Project in Visual Studio.
Install NUnit and NUnit3TestAdapter via NuGet.
Add a reference to the project containing the code you want to test.

Step 2: Write a Failing Test

Let’s use TDD to build a Calculator class with an Add method. First, create a test class CalculatorTests.cs and add this test:

using NUnit.Framework;

[TestFixture]
public class CalculatorTests
{
    [Test]
    public void Add_TwoNumbers_ReturnsSum()
    {
        var calculator = new Calculator();
        int result = calculator.Add(2, 3);
        Assert.AreEqual(5, result); // This test will fail since the method doesn’t exist yet
    }
}

Step 3: Write Just Enough Code to Pass the Test

Since our Calculator class and Add method don’t exist yet, let’s create them:

public class Calculator
{
    public int Add(int a, int b) => a + b;
}

Run the test—it should now pass!

Step 4: Add More Tests and Implement Subtraction

Next, let’s implement a Subtract method using the same TDD approach.

Write a test first:

[Test]
public void Subtract_TwoNumbers_ReturnsDifference()
{
    var calculator = new Calculator();
    int result = calculator.Subtract(5, 3);
    Assert.AreEqual(2, result); // This test will fail initially
}

Write just enough code to pass the test:

public int Subtract(int a, int b) => a - b;

Refactor if needed to keep your code clean and efficient.

Step 5: Run and Verify Your Tests

Use Visual Studio’s Test Explorer to run all your tests. If they pass, congrats! You’ve successfully followed the TDD cycle.

How TDD Improves Code Structure

If TDD is applied properly, the following structural benefits emerge:

Loose Coupling: Since tests require isolating components, TDD encourages designing classes that don’t depend too much on each other.
Dependency Injection: Writing testable code often means injecting dependencies instead of hardcoding them, leading to better modularity.
Composition Over Inheritance: Rather than relying too much on inheritance, TDD pushes towards a composition-based approach, making code more flexible.
Separation of Concerns: Following the TDD cycle helps ensure each class has a single responsibility, making it easier to maintain and extend.
Improved Testability: The necessity to test first forces developers to create well-structured, reusable components that are easier to test in isolation.

Pro Tips for Writing Good Unit Tests

Stick to the AAA (Arrange-Act-Assert) pattern to keep tests clean and readable.
Make tests independent—don’t let them rely on external data or states.
Use mocking frameworks like Moq to isolate dependencies.
Keep tests fast and focused—each test should check just one thing.
Avoid over-testing trivial methods like simple property getters.

Wrapping Up

Unit testing (especially with TDD) makes your code more reliable, easier to maintain, and less prone to bugs. Since each test case describes a specific use case, they double as a form of documentation for how your code is expected to behave. Additionally, applying TDD properly leads to better code structure through dependency injection, loose coupling, and composition-based patterns.

In the next post, we'll dive deeper into mocking —an essential technique for isolating dependencies and making unit tests more effective. Stay tuned!

DEV Community: Mirnes

Understanding the Lifecycle of a .NET Core Web API Request

1. Application Startup

2. HTTP Request Pipeline (Middleware)

3. Routing and Endpoint Matching

4. Model Binding and Validation

5. Controller Action Execution

6. Result Execution

7. Middleware Response Processing

8. Response Sent to Client

Conclusion

Premature Optimization

What Is Premature Optimization?

Why It’s a Trap

1. Wasted Time and Effort

2. Complexity Without Justification

3. Inhibits Flexibility

4. Violates YAGNI (You Aren’t Gonna Need It)

When Optimization Does Matter

Best Practices to Avoid the Trap

Conclusion

Design Patterns: Adapter

When to Use the Adapter Pattern

Implementing the Prototype Pattern in C#

Create the Adapter

Client

Benefits

When Not to Use It

Conclusion

Web API Versioning and Testing

API Versioning?

Step 1: Install Required Package

Step 2: Configure Versioning in Program.cs

Step 3: Create a Versioned Controller

Setting Up a Test Project

Step 1: Create a New Test Project

Step 2: Writing Unit Tests for Services

Summary

Web API Architecture: Services and Repositories

Why Clean Architecture?

Proposed Project Structure

Lets Create Migration With Some Test Data

Repository

Service

Register all in Program.cs

Controller

Summary

Coming Up Next…

Web API Exception Handling and Logging

Why Global Error Handling?

Creating Global Error Handling Middleware

Registering the Middleware

Setting Up NLog in .NET 9

Install the NLog packages

Add a nlog config to appsettings.json file

Load NLog config in Program.cs

Add logger to ExceptionHandlingMiddleware.cs

Creating the Logs Table with FluentMigrator

Coming Up Next…

Web API Project Setup and Migrations

In This Post

Step 1: Create the API Project

Understanding the Project Structure

Program.cs

appsettings.json

Controllers/

Step 2: Create a Separate Migrations Project

Why put migrations in a separate class library?

Create the migration library

Step 3: Create Your First Migration

About the [Migration] attribute

Step 4: Configure FluentMigrator in the Web API

Coming Up Next…

Understanding State Machines with a Practical Example in C#

What is a State Machine?

Why Use a State Machine?

Implementing a State Machine in C#

Use Case: Order Processing System

States and Transitions

C# Implementation

Register all in `Program.cs`

Add a `nlog` config to `appsettings.json` file

Load NLog config in `Program.cs`

Add logger to `ExceptionHandlingMiddleware.cs`

Creating the `Logs` Table with FluentMigrator

`Program.cs`

`appsettings.json`

`Controllers/`

About the `[Migration]` attribute