DEV Community: Mirnes

ASP.NET Core Request Lifecycle Explained: From HTTP Request to Response

Mirnes — Wed, 08 Jul 2026 06:21:10 +0000

When we send a request to a .NET Core Web API, it goes through 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 prebuilt functionalities. Diagram bellow shows the entire request - response pipeline.

Middleware Request Processing

When HTTP request hits .NET Core Web API, it first goes trough pipeline of asynchronous delegates RequestDelegate that can intercept and process the HttpContext before routing occurs. Each of them can be configured in Program.cs and each middleware executes short-lived logic before invoking await next(context) to pass the request down the execution chain.

Key things happening at this phase are:

Authentication/Authorization: Validates incoming JWT or cookie tokens to populate the HttpContext.User identity principal.
CORS Policy Evaluation: Inspects origin headers and injects cross-origin access rules into the request context.
Global Error Interception: Wraps the downstream pipeline in a try-catch block to catch unhandled runtime exceptions early.

An important mechanism here is pipeline short-circuiting. If a middleware component detects a validation failure (such as a missing access token), it skips invoking next() and populates the response payload, sets the termination HTTP status code (e.g., 401 Unauthorized), and immediately returns the result, completely bypassing downstream routing and controller actions.

Routing and Endpoint Matching

Routing determines which controller and action should handle the request. This process is split into a two-step middleware mechanism:

Endpoint Routing (UseRouting): This step parses the incoming URL path, query string, and HTTP verb (GET, POST, etc.). It matches these values against the application’s compiled routing tree, selects the single best-matching route candidate, and attaches that endpoint metadata directly to the HttpContext.
Endpoint Execution (UseEndpoints): After intermediate middleware (such as Authorization) evaluates the selected endpoint’s policies, this component triggers the endpoint’s underlying RequestDelegate, triggering the controller action to execute.

Model Binding and Validation

After the endpoint is matched, the raw data is taken out of the HTTP request and being converted into strongly typed C# objects before passing them to the controller action. It maps data from the route path [FromRoute], query string [FromQuery], request headers [FromHeader], or parses the JSON payload from the request body [FromBody].

Once the C# object is populated, the framework evaluates data annotations applied to the target class ([Required], [StringLength], [EmailAddress], etc.) or custom validators. If validation fails, the framework can automatically return a 400 Bad Request.

Controller Action Execution

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

Dependency Injection: The controller is instantiated and required services are injected (such as database contexts, logging instances, or custom services)
Asynchronous Execution: The framework invokes the matched action method asynchronously, and returning a Task<IActionResult>. This keeps threads free to be able to handle other traffic and not be blocked by the code that waits on heavy tasks, like database queries or external API calls.
The Return Result: The controller’s primary job is not to build the actual HTTP response payload, but simply to return an object that implements IActionResult (such as Ok(), NotFound(), or BadRequest()).

Result Execution

This step marks the entry point into the response pipeline. Its job is to take the abstract IActionResult returned by the controller and translate it into a concrete action plan for the network response. The framework executes this transformation using these steps:

Result Processing: The runtime matches the type of IActionResult to an executive class (for example, an OkObjectResult triggers an ObjectResultExecutor). This executor analyzes the raw C# object data contained inside the result.
Content Negotiation: The executor inspects the incoming request’s Accept headers to determine what format the client prefers (such as application/json or application/xml). It then selects the correct output formatter based on those preferences.
Serialization Preparation: The data object is serialized into the chosen format. While formatting happens here, the raw bytes are held in a memory buffer rather than being dumped straight onto the live network stream. This buffer allows later response middleware to inspect or alter headers safely before transmission.

Middleware Response Processing

After result execution, the control is returned to the exact same middleware components initialized during the request phase, and to the code written after their await next(context) statements. At this stage, middleware can:

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).

This is the final point where behavior can be influenced before the response goes back to the client. Before the first byte of data is sent over the network, response headers are permanently locked and they can no longer be modified.

Response Sent to Client

Finally, the HTTP response is sent back to the client. The web server flushes the buffered response body and HTTP headers directly into the network socket stream. The connection is then cleaned up and resources are disposed via the dependency injection container. At this point, the request lifecycle is complete.

The .NET Core Web API request lifecycle is powerful and highly extensible. If we correctly understand each step, we can design better APIs and create a maintainable architecture that scales well.

Happy coding!

Vibe Coding Traps and Delusions

Mirnes — Mon, 22 Jun 2026 09:00:00 +0000

For a long time, I am thinking about writing something on this topic, but since I was not sure about my thoughts and how to formulate them, I kept silent. The last few months things are getting clearer in my mind, so here I am to express my opinion on current AI development and its influence on software engineering industry and everyday tasks of one developer. I am writing this post in hope that my experience of more than one year actively using LLMs and agents in coding could help someone who is struggling with the entire idea behind.

Productivity Fallacy

We all heard big announcements on how AI is boosting productivity of developers by 20% - 30% and once when something is in public space as the mainstream idea, it is not so convenient to speak against it. Main industry drivers are making fortune based on that assumptions and it is not popular to be against the idea, or, like in my case, to be less for it as the main narration suggests. I would say that, even, it is not so hard as it is meaningless having in mind that your opinion won’t make any difference.

LLMs are indeed helping to write code, or better said, to generate text. This is in the end the idea of large language models -> meaningful text generation. The main trap here is that, as a developer, you get a sense of large productivity because suddenly you are generating large amount of code in seconds. Having this metric in the head, productivity percentage from the beginning of the last paragraph is definitely true. What is important here is that the same code needs to be read and proven if it is working as it should.

Before, when you got the task, you would think first on how to implement it and then start with small portions, writing everything on your own, or reading docs of other libraries to be sure how to call their interfaces, etc. In that process, your cognitive focus was entirely on the code writing and in the same time understanding what it is doing.

On the other hand, with the AI generating the code, you don’t have anymore same cognitive process, but the cognitive load is shifting towards code review. OK, we can say, we are still good if we do the review faster than we used to write code before. Indeed, that is true, but here lie two things to consider:

AI, by default, is generating more code than we wrote before for the same tasks. Having this in mind, code review is longer and it is harder to get entire context at once of what is written, because you have so much code to take a look at.
Code review is not the same as writing the code. Here is the big difference; we can compare it with writing the book and reading the book. Does the same understanding of the book content has its author and the reader? Same is happening here with the code. We will produce anomalies where people who are standing behind pull requests do not remember what that code is doing in a longer run.

Fears On Productivity

If the main measurement of the productivity is the number of generated lines of code, this is already steered in wrong direction, because it will result in two things:

Developers will spend less time reviewing because they compete to write the new code. Reviewing it is not something what brings an award.
With less code review comes the even lesser understanding of what code does.

Both things are extremely dangerous in a long run. What will happen when something breaks in production; who can resolve it and take responsibility of the change on the code that he/she does not understand?

AI Assisted Coding vs AI Driven Coding

Another aspect what I tend to see is that vibe coding is steering the idea of AI assisted coding towards AI driven coding. Responses from AI agents are being more and more persuasive and many developers tend to put all trust in it, having less critical approach. This makes the game more complicated because it twists around the roles of main driver and his assistant. If we combine this with the statements from the last two paragraphs, we can imagine in which direction it can lead.

With the last development on skills and AI bots doing the review on every pull requests, insisting on the human code review has to be bigger than ever. If we rely on bot doing the code review and then pasting the bot comments into prompt asking for the changes, or even when bot automatically creates a changes for us, that is already concerning and should raise the question about who is steering the development and who shall be the main driver. These things could have a big cost in the future when something goes wrong, and it always will. Some things will go wrong, it is just matter of time and cost in the end.

Asset vs Liability

Code is not an asset, it is a liability. The asset is its functionality which brings money when it is put in production. But every new line of code is liability by default because it is a technical debt, it requires maintenance and therefore spends money. And more you have of it, you are more down in that debt spiral. Less code which is doing its job shall be the main focus.

Therefore, productivity measurement which relies on how many lines of code one developer is generating does not make any sense. In fact, it only has a negative impact because, as an output, it has less code reviews and more generated code.

Final Thoughts

AI agents are very helpful when used carefully. Asking it to explain you and summarize what some portion of legacy code does is extremely helpful. Asking it to write an unit of code which you steer from the beginning to the end and having full focus on it is extremely helpful. AI bots which are doing the review are helpful, can find edge cases which you didn’t think of during the development. All of these things can really be used as a benefit, but not as the only source of truth.

Some of the lessons I have learned so far is to aim to write less code as possible, because that is one of the ways how you can still keep yourself focused and not lose the track. Also, when bug-bot does the review, you should ask yourself if that comment makes sense in the business logic you are expecting to implement. Be critical, be more critical on the review, same as you would be for someone who is touching the code base for the first time. This will help to break the illusion which agent is giving persuading you that it did the correct thing by default.

Why Body Language Is Important for a Software Developer

Mirnes — Sat, 20 Jun 2026 10:56:49 +0000

When we think of software developers, we often imagine them focused only on the (messy) code. But in an usual collaborative work environment, technical skills alone are not enough. Body language does significantly influence how you are perceived, how you connect with your team, and how effectively you convey your ideas. We will try here in a few points to summarize why body language is important for developers and what we should pay attention to:

1. Improves Team Communication

Developers regularly work in teams; they participate in daily stand-ups, code reviews, brainstorming sessions, internal workshops… Positive body language like an eye contact, open posture, and nodding shows attentiveness and fosters trust, helping ideas flow more easily.

2. Boosts Leadership Presence

As developers grow into senior roles or team leads, their ability to inspire and influence others becomes crucial. Confident body language supports verbal communication and reinforces authority and clarity.

3. Enhances Presentation Skills

Whether you’re demoing a project or explaining a complex architecture to non-technical stakeholders, your gestures, facial expressions, and posture can make the difference between confusion and clarity.

4. Reduces Miscommunication

In diverse teams, especially in cross-cultural ones, body language can be beneficial where words may fail. Being aware of your own non-verbal signals and interpreting others’, can prevent potential misunderstandings.

5. Improves Interviews and Career Growth

Whether you’re applying for a job or seeking internal promotion, your body language during interviews or meetings plays a crucial role in how competent, confident, and trustworthy you may seem.

As Software Engineers, most of us are not so good in the social skills by default, we have to accept that. On the other hand, these skills can be learned, step by step. There are some of the good books out there that could help in this case. I have prepared a list of my favourites on my original blog post https://optimalcoder.net/why-body-language-is-important-for-software-developer/
Happy reading!

Premature Optimization in Software Development: Examples, Risks, and Best Practices

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. You can end up solving problems that do not exist, or worse, introduce complexity into a system that was already working well.

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 its 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 Is It a Trap?

Solving The Wrong Problem

First thing is to understand what are you trying to solve, when and how it will be used, who will use it, with which data, etc. All these questions can help you to understand what is the real problem you need to solve.

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 understanding the actual workload, you are optimizing based on assumptions rather than evidence.

Readability and Maintenance

Then it comes readability and the maintenance. Optimized code is often more complex and harder to read or maintain. Considering that the code is read far more often than it is written, trade-off is clear. If the performance gain isn't needed, all you are left with is unnecessary complexity. In other words, that is a debt that you or your teammates will have to pay later. The code is not an asset, it is a liability.

Over-optimized code is often not flexible. It is tuned for a specific case and harder to refactor or extend. As project requirements evolve, what is always the case, this premature rigidity can significantly slow progress and reduce adaptability.

The Delusion of Performance Importance

Software engineering is fundamentally about trade-offs. A graphics driver and an ERP system are both software, but they solve fundamentally different problems. One is expected to squeeze every cycle out of the hardware and the other is expected to model business rules accurately. If you try to apply the same optimization mindset to both, that is a category mistake.

Performance should not be an absolute goal, but a requirement defined by a domain. The importance of performance depends on the needs of the users, the nature of the product, and the constraints under which that software operates.

Of course, this does not mean that we should completely ignore obvious algorithmic problems, as shown bellow.

foreach (var user in users)
{
    if (orders.Any(o => o.UserId == user.Id))
    {
        ...
    }
}

This is problematic for large number of users and orders, it can be O(n²) complexity and should be avoided with something like:

var orderUserIds = orders.Select(o => o.UserId).ToHashSet();

foreach (var user in users)
{
    if (orderUserIds.Contains(user.Id))
    {
        ...
    }
}

Premature optimization should not be confused with choosing appropriate algorithms and data structures for the problem we are trying to solve. In the example above, choosing a HashSet instead of repeatedly scanning a list, is good engineering rather than premature optimization.

Some of The Premature Optimization Examples

Using StringBuilder for tiny strings

var sb = new StringBuilder();
sb.Append(firstName);
sb.Append(" ");
sb.Append(lastName);

return sb.ToString();

Instead of:

return $"{firstName} {lastName}";

StringBuilder is beneficial when you're performing many concatenations, such as inside large loops.

Replacing readable LINQ with manual loops everywhere

Customer? found = null;

foreach (var customer in customers)
{
    if (customer.Id == id)
    {
        found = customer;
        break;
    }
}

Instead of:

var found = customers.FirstOrDefault(c => c.Id == id);

Only replace LINQ after profiling shows it is actually a bottleneck.

Replacing simple code with bit tricks
```
bool isEven = (number & 1) == 0;
```
Instead of:
```
bool isEven = number % 2 == 0;
```
Modern JIT compilers are excellent at optimizing simple arithmetic. The readability loss is rarely worth it.
Avoiding exceptions for code that almost never fails

Instead of:
```
try
{
    ProcessFile(path);
}
catch (IOException)
{
    // Handle error
}
```
someone writes complicated pre-checks everywhere because "exceptions are expensive."
Exceptions are expensive, but only when they are thrown. If errors are exceptional, the simpler version is often better.

When Optimization Does Matter

Of course, optimization has its place, but after you have measured performance and identified real bottlenecks. This approach ensures that your efforts are focused where they will have a real impact.

A few places where early attention to performance is justified include systems where performance is a primary requirement, such as:

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

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

Some of the rules that could be followed to avoid unnecessary complexity are:

Profile Before Optimizing: Use tools to measure real performance and identify hot-spots.
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 can be delusional. It feels like you are 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 there is evidence that performance matters, either when it is an explicit requirement or because profiling has identified a real bottleneck.

In the end, main idea is to write code that works, which is easy to read and maintain. If it is slower then expected, then do the optimization, not before you have the concrete data.

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.
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 are great way to encapsulate complex logic where we have multiple transitions between one state to another with different conditions. It can be used to avoid complex if-elseif-else or switch-case statements in the way which is elegant and easy to read. In the end it is easier to track and debug state changes and new states and transitions can be added without major changes.

What are the Parts of one State Machine?

State machine consists of:

States : Different conditions or modes the system can be in. State in this sense can be anything which represents the current mode or property of one object inside the memory. Some of examples in real world are:
- light switch: on - off
- door: open - closed - locked - unlocked
- task: ready - in progress - in review - deployed - done - cancelled
- blog post: draft - archived - deleted - published
- order: pendingPayment - processing - shipped - delivered - cancelled
Events : Triggers that cause state transitions.
- In the case of door, it can be Enter PIN correctly. This is the trigger which moves door from state locked to unlocked
- In the case of order, it can be pay the order, which moves order from pendingPayment to processing
Transitions : Rules that define how the system moves from one state to another. This is basically description of the entire process in order for the state to be changed.
Actions : Operations performed when entering, exiting, or staying in a state. This is somehow reflection to the outer world.
- In our door example, it can be that when the False PIN entered that we have action to turn the alarm on together with the door stayed in locked state.
- In the case of order, it can be when order is paid, to give signal for packaging on the other side.

Practical Example in C#

Imagine you’re building an e-commerce application that handles order statuses. An order can go through several states before completion. We can show a visual representation as follows.

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)
Actions :
- OrderPaid (notify externally that order is paid)
- OrderShipped (notify externally that order is shipped)

Implementation

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

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 }

    public event EventHandler? OrderShipped;
    public event EventHandler? OrderPaid;

    private Dictionary<TransitionFrom, TransitionTo> _stateTransitions;
    public OrderState CurrentState { get; private set; }


    private record TransitionFrom(OrderState State, OrderTrigger Trigger);
    private record TransitionTo(OrderState State, Action? Action);

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

    public void ProcessTransition(OrderTrigger trigger)
    {
        if (_stateTransitions.TryGetValue(new (CurrentState, trigger), out TransitionTo newState))
        {
            Console.WriteLine($"Moving from {CurrentState} to {newState.State} due to {trigger}");
            CurrentState = newState.State;
            newState.Action?.Invoke();
        }
        else
        {
            Console.WriteLine($"Invalid transition: {CurrentState} cannot handle {trigger}");
            throw new InvalidOperationException($"Invalid transition: {CurrentState} cannot handle {trigger}");
        }
    }

    private void OnOrderPaid()
    {
        OrderPaid?.Invoke(this, EventArgs.Empty);
    }

    private void OnOrderShipped()
    {
        OrderShipped?.Invoke(this, EventArgs.Empty);
    }
}

Client :

var orderStateMachine = new OrderStateMachine();
orderStateMachine.OrderPaid += OrderStateMachine_OrderPaid;
orderStateMachine.OrderShipped += OrderStateMachine_OrderShipped;

Console.WriteLine($"Initial state: {orderStateMachine.CurrentState}");

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


void OrderStateMachine_OrderPaid(object? sender, EventArgs e)
{
    Console.WriteLine($"Order is paid. We need to package the order");
}
void OrderStateMachine_OrderShipped(object? sender, EventArgs e)
{
    Console.WriteLine($"Order is shipped. Notify customer!");
}

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 Action notifies external world that something happened inside the state machine on which caller shall react.

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 nice 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 a great software. They help to maintain code quality, catch bugs early, improve mentorship and collaboration withing the team. But if done poorly, they can be frustrating, time-consuming, and even demotivating, what could lead to the situation when they are not done at all, which is the worst case scenario.

First thing to consider is to keep pull requests smaller as the code review in this case will be faster and more effective. We should break big changes into smaller and focused updates.

Make Sure the Code Solves the Right Problem

What we need to do when accessing the code review is to confirm that the implementation matches the given requirements. Solving wrong problem is not of help here. Same goes with not solving the problem in the right way. Take the time to understand the code before commenting and avoid approvals without actually checking the details. LGTM comments are not useful in most cases except if the change is one line or too obvious.

If there are UI changes, we need to make sure they align with design specifications, and that application visually does not look weird or with design break.

Code Quality and Performance

Then, we need to be sure that code follows best practices and styling guidelines. There are plenty of tools (depending on the language) that can help to ensure styling guidelines are respected and they can be hooked inside the CI pipeline when the pull request is raised. It does not make sense to do these things manually when they can be automated. Next thing to consider is that best practices are in place, if the feature is easily extensible, if it follows existing code structure, etc.

Performance is another thing we should pay attention to, if we see that something could be done in different way to make the code execution faster, to avoid unnecessary complexity, etc. Here we should also pay attention to database queries, if they are written in a good way, especially when some ORM is used because often it hides additional complexity on queries which are executed on the database level.

Security and Testing

Next, we need to make sure that newly written piece of code will not have any security leak. This usually means to pay attention on potential risks of SQL injection, XSS, hardcoded secrets, missing input validations on both client and server side, etc.

Look for unit tests and integration tests where needed. Good practice here is also to have them included in CI pipeline, so the tests are already run and passed before you take a look at the code. Pay attention on the edge cases and possible failure points.

Give Constructive, Respectful Feedback

One of the most important things is the way how the feedback is given. This is sometimes crucial point and it reflects overall team culture. We need to focus on helping and not to be there as a judge who will just point on mistakes. Offering suggestions is way much better than focus on criticism. If critique needs to be given, criticize the code and not the developer. In the end, we need to know that everyone is making mistakes, no matter how experienced.

Good practice here is to first praise on what is done well, and then slightly change the direction to the areas that would need some improvement. With this approach, other person is feeling appreciated without finger pointing on the mistakes. After all, code is responsibility of the entire team together. In the same time, this is very good way for the older colleagues to practice mentorship.

Another thing to pay attention to is that suggestions are practical and easy to follow and in the same time that they avoid unnecessary refactoring unless it truly improves the code. Code reviews which are going back and forth just for the reviewer to be happy although it does not bring any real value should be avoided because it can lead to frustration on the other side. Other aspect is that then code review takes more time than needed and team is unnecessary loosing its speed.

Final Thoughts

Code reviews should be a positive and collaborative process. They are not just about finding mistakes but making the code better and helping each other to grow as developers. Keeping feedback constructive, focusing on maintainability, and using automation where you can will make the process smoother. Most importantly, we should remember that you are all on the same team, and that you are improving your product together.

DEV Community: Mirnes

ASP.NET Core Request Lifecycle Explained: From HTTP Request to Response

Middleware Request Processing

Routing and Endpoint Matching

Model Binding and Validation

Controller Action Execution

Result Execution

Middleware Response Processing

Response Sent to Client

Vibe Coding Traps and Delusions

Productivity Fallacy

Fears On Productivity

AI Assisted Coding vs AI Driven Coding

Asset vs Liability

Final Thoughts

Why Body Language Is Important for a Software Developer

1. Improves Team Communication

2. Boosts Leadership Presence

3. Enhances Presentation Skills

4. Reduces Miscommunication

5. Improves Interviews and Career Growth

Premature Optimization in Software Development: Examples, Risks, and Best Practices

What Is Premature Optimization?

Why Is It a Trap?

Solving The Wrong Problem

Readability and Maintenance

The Delusion of Performance Importance

Some of The Premature Optimization Examples

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

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