DEV Community: Mirnes

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!

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!

DEV Community: Mirnes

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

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?

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