DEV Community: Mirnes

JWT Authentication in ASP.NET Core Web API: Access and Refresh Tokens

Mirnes — Wed, 19 Aug 2026 10:48:38 +0000

Most APIs need a way to identify their clients and protect resources from unauthorized access. JWT authentication provides a simple and widely used approach for handling this in stateless Web APIs. This article explains how JWT authentication works in ASP.NET Core and demonstrates its implementation step by step. For simplicity, we will assume that a user already exists in the database. User registration is outside the scope of this article.

Design

Then, let us introduce some design around our authentication component and show how these different classes are working together. Requests are being handled in AuthenticationController, then dataflow is being handed over to AuthenticationServicewhich contains the main logic. AuthenticationServicehas the communication with the database via UserDbContext. With this, we have segregated our responsibilities across different classes based on their abstraction layer. More detailed explanation of the different data flows and components included is shown in two diagrams below.

Login

Authenticated Request

Authentication Flow

From the functionality perspective, token authentication flow is as follows:

User types in username and password and if credentials are valid, two tokens are returned to the client: access and refresh token.
Access token is used for accessing other endpoints where authentication is required, whereas refresh token is used once the access token expires and needs refresh.
When the client later requests a token refresh, the supplied token is hashed and compared with the stored value. Each successful refresh also generates a new refresh token and replaces the stored hash. This means a refresh token is effectively single-use.
In the database, we are storing just refresh token hash, so raw tokens are available only to the real user.

Controller

Now, let us move on with AuthenticationControllerwhich acts like an interface to the outside world. For the scope of this article, we will implement login, refresh token and logout mechanism.

 [Route("api/[controller]")]
 [ApiController]
 public class AuthenticationController : ControllerBase
 {
    private readonly IAuthenticationService _service;

    public AuthenticationController(IAuthenticationService service)
    {
        _service = service;
    }

    [AllowAnonymous]
    [HttpPost("Login")]
    public IActionResult Login([FromBody] UserLoginModel user)
    {
        var tokenModel = _service.Login(user);
        return Ok(new { TokenModel = tokenModel });
    }

    [AllowAnonymous]
    [HttpPost("RefreshToken")]
    public IActionResult RefreshToken([FromBody] TokenRequest request)
    {
        var tokenResponse = _service.RefreshToken(request);

        return Ok(tokenResponse);
    }

    [Authorize]
    [HttpPost("Logout")]
    public IActionResult Logout([FromBody] TokenRequest tokenModel)
    {
        var success = _service.Logout(User.Identity?.Name!, tokenModel);

        return Ok(success);
    }
 }

Service

Furthermore, the logic around authentication is going inside the AuthenticationService. Here, we are injecting JWT configuration from appsettings.json. We didn’t put Key, which you will need to put on your own if you want to try the code. Key is the secret used to sign the access token and it should not be committed to source control. In the prod environment it should be managed in some secret-management mechanism.

    "Jwt": {
    "Key": "",
    "Issuer": "optimalcoder.net",
    "Audiences": [
        "https://localhost:44322/"
    ],
    "TokenValidityInMinutes": 1,
    "RefreshTokenValidityInDays": 7
}

public interface IAuthenticationService
{
    TokenResponse Login(UserLoginModel user);
    TokenResponse RefreshToken(TokenRequest request);
    bool Logout(string username, TokenRequest request);
}

public class AuthenticationService : IAuthenticationService
{
    private readonly UserDbContext _userDbContext;
    private readonly IPasswordService _passwordService;
    private readonly Jwt _jwtConfig;

    public AuthenticationService(UserDbContext userDbContext, IPasswordService passwordService, IOptions<AppSettings> appSettings)
    {
        _userDbContext = userDbContext;
        _passwordService = passwordService;
        _jwtConfig = appSettings.Value.Jwt;
    }


    public TokenResponse Login(UserLoginModel model)
    {
        var user = _userDbContext.User.FirstOrDefault(x => x.UserName == model.UserName);

        if (user == null)
        {
            throw new UnauthorizedException("INVALID_CREDENTIALS", "Invalid username or password.");
        }

        var passwordValid = _passwordService.Verify(user, model.Password, user.PasswordHash);

        if (!passwordValid)
        {
            throw new UnauthorizedException("INVALID_CREDENTIALS", "Invalid username or password.");
        }

        var authToken = GenerateAuthToken(user);
        var refreshToken = GenerateRefreshToken();

        user.RefreshTokenHash = HashRefreshToken(refreshToken);
        user.RefreshTokenExpiryTime =
            DateTime.UtcNow.AddDays(
                _jwtConfig.RefreshTokenValidityInDays);

        _userDbContext.SaveChanges();

        return new TokenResponse
        {
            AuthToken = authToken,
            RefreshToken = refreshToken
        };

    }

    public TokenResponse RefreshToken(TokenRequest request)
    {
        var refreshTokenHash = HashRefreshToken(request.RefreshToken);

        var user = _userDbContext.User.FirstOrDefault(x => x.RefreshTokenHash == refreshTokenHash);

        if (user == null || user.RefreshTokenExpiryTime <= DateTime.UtcNow)
        {
            throw new UnauthorizedException("REFRESH_TOKEN_FAILED", "Refresh token failed.");
        }

        var newAuthToken = GenerateAuthToken(user);
        var newRefreshToken = GenerateRefreshToken();

        user.RefreshTokenHash = HashRefreshToken(newRefreshToken);

        user.RefreshTokenExpiryTime = DateTime.UtcNow.AddDays(_jwtConfig.RefreshTokenValidityInDays);

        _userDbContext.SaveChanges();

        return new TokenResponse
        {
            AuthToken = newAuthToken,
            RefreshToken = newRefreshToken
        };
    }

    public bool Logout(string username, TokenRequest request)
    {
        var refreshTokenHash = HashRefreshToken(request.RefreshToken);

        var user = _userDbContext.User.FirstOrDefault(x => x.UserName == username &&
            x.RefreshTokenHash == refreshTokenHash);

        if (user == null)
        {
            throw new UnauthorizedException("LOGOUT_FAILED", "Invalid refresh token.");
        }

        user.RefreshTokenHash = null;
        user.RefreshTokenExpiryTime = null;

        _userDbContext.SaveChanges();

        return true;
    }

    private string GenerateAuthToken(User user)
    {
        var claims = CreateClaims(user);

        var securityKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtConfig.Key));

        var credentials = new SigningCredentials(securityKey, SecurityAlgorithms.HmacSha256Signature);

        foreach (var audience in _jwtConfig.Audiences)
        {
            claims.Add(new Claim(JwtRegisteredClaimNames.Aud, audience));
        }

        var tokenDescriptor = new JwtSecurityToken(
            issuer: _jwtConfig.Issuer,
            claims: claims,
            expires: DateTime.UtcNow.AddMinutes(_jwtConfig.TokenValidityInMinutes),
            signingCredentials: credentials);

        return new JwtSecurityTokenHandler().WriteToken(tokenDescriptor);
    }

    private static string GenerateRefreshToken()
    {
        var randomNumber = new byte[64];

        using var rng = RandomNumberGenerator.Create();

        rng.GetBytes(randomNumber);

        return Convert.ToBase64String(randomNumber);
    }

    private static string HashRefreshToken(string refreshToken)
    {
        var hash = SHA256.HashData(Encoding.UTF8.GetBytes(refreshToken));

        return Convert.ToBase64String(hash);
    }

    private List<Claim> CreateClaims(User user)
    {
        var claims = new List<Claim>();

        claims.Add(new Claim(ClaimTypes.Name, user.UserName));

        return claims;
    }
}

Because access tokens are stateless, logging out just removes the stored refresh token, preventing the client from obtaining a new access token after the current access token expires. Next valid operation can only be new login. Other logic like token generation can be easily understood from the code itself, and therefore no need for additional explanations here.

Database

UserDbContextis simply the persistence layer used by this example. The same authentication service can work with a different persistence implementation, such as the repository approach described in DB repositories and services.

public class UserDbContext : DbContext
{
    public UserDbContext(): base()
    {

    }
    public UserDbContext(DbContextOptions<UserDbContext> options)
   : base(options)
    { 
    }

    public virtual DbSet<User> User { get; set; }

}

Middleware

Validation of the username and password, together with other exceptions inside the AuthenticationServiceare done trough UnauthorizedException, so it can be easily preprocessed at the ExceptionMiddlewareand returned as an unified response inside the ProblemDetails to the client.

public class ExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;

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

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

    private async Task HandleExceptionAsync(HttpContext context, IOptimalLogger logger, Exception ex)
    {
        ProblemDetails response;

        switch (ex)
        {
            ...
            case UnauthorizedException unauthorizedEx:
                response = CreateErrorResponse(StatusCodes.Status401Unauthorized, unauthorizedEx.Code, ex.Message);
                break;
            ...

        }

        context.Response.StatusCode = response.Status;
        context.Response.ContentType = "application/json";

        await context.Response.WriteAsJsonAsync(response);
    }


    private static ProblemDetails CreateErrorResponse(
    int status,
    string code,
    string message)
    {
        return new ProblemDetails
        {
            Status = status,
            Detail = message,
            Title = code
        };
    }
}

Dependency Injection

In the end, let us take a look at the code snippets which are needed to wire everything up. We are defining which service will be injected inside the DI container and how Authentication is handled by the framework. The remaining configuration is omitted for clarity.

        ...
        services.AddScoped<IAuthenticationService, AuthenticationService>();
        services.AddScoped<IPasswordHasher<User>, PasswordHasher<User>>();
        services.AddScoped<IPasswordService, PasswordService>();
        ...
        ...
        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
                .AddJwtBearer(jwtOptions =>
                {
                    jwtOptions.TokenValidationParameters = new TokenValidationParameters
                    {
                        ValidateIssuer = true,
                        ValidateAudience = true,
                        ValidateLifetime = true,
                        ValidateIssuerSigningKey = true,
                        ValidAudiences = jwt.Audiences,
                        ValidIssuer = jwt.Issuer,
                        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwt.Key))
                    };
                });

        ...

        ...
        services.AddAuthorization();
        ...
        app.UseAuthentication();
        app.UseAuthorization();
        ...

Want to check the complete implementation?
The article focuses on the parts of the implementation that are useful for understanding. The entire source code is available on my github repository.
Explore more →

How to Review Code in The Age of AI

Mirnes — Thu, 06 Aug 2026 10:27:52 +0000

As AI agents can write code much faster than any human developer ever could, and as we get hundreds if not thousands lines of code as a results of one prompt, the need for careful code review is greater than ever. This remains the primary mechanism for ensuring that code is following engineering guidelines, architectural principles and in the same time ensures long-term maintainability and extensibility.

In one of my previous posts about vibe coding traps and delusions I have shared my thoughts on why and how the cognitive load is shifted from the code generation to the code review and why I think this is the topic that should attract more and more attention from fellow developers. In this article, I describe how I see the approach to the code review after more than a year of actively working with coding agents.

Active Code Review By The Author

Before requesting a peer review, the author should perform an active review of the generated code as if they were reviewing someone else’s work. Before AI, developers usually understood every line because they had actively participated in writing the code. Today, developers often guide the implementation rather than author every detail of it. With that being said, making an explicit self-review becomes much more important in order to be sure that agent generated what is intended.

This can be understood as a logical step, but as agents are writing comprehensive implementations and the syntax of the generated code appears to be very persuasive, it is not hard to believe everything what comes as an output from the agent is correct and to not pay enough attention on details. First thing that needs to be checked is if the generated code aligns with the architecture principles in the product and if the code is solving the right problem or inventing new one.

Another step is to try to do the same functionality with less code as possible. As LLMs by default are generating more code, sometimes more complex as it should be, we need to check if all that code is needed. In most cases it can be simplified, and we should insist on it as much as possible. Of course, at the beginning you will be in situation that you need to prompt back and forth till the desired output is given, but this is also the process where you can learn how to steer your agent in the way that fit your needs.

In the process, you will discover some patterns what fit your workflow, so you can define skills for the agent. In that way you already have predefined input for the agent next time you need some repetitive task. Both skills and rules can be used to streamline the code generation process. However, neither skills nor rules eliminate the need for careful code review. In the end, the author remains responsible for every line that is submitted.

Automated Review

Once the developer is ready to open a pull request, another step is often executed automatically as part of the CI pipeline. Here, the AI agent is doing automated review on the posted code and can find some very interesting edge cases, potential security risks or missing null checks. In the same time it still lacks the full business and historical context of the project. It may recommend changes that are technically reasonable but inappropriate for the product or existing architecture.

Here, the developer again should pay full attention on the feedback from automated reviewer to check if the review makes sense and if it is worth to be implemented. Again, we can expect here lot of suggestions, depending on the size of the pull request. Large AI generated pull requests often trigger a significant number of automated review comments. This is another reason to keep changes as small and focused as possible, to be able to carefully review them.

Code Review By Peer

If all previous steps are done correctly, then this stage should not take too much time, because much of the confidence should already come from the author’s own review and the automated review. This stage then is basically similar as the old fashioned code review before AI. Deep insights into this can be found in one of my older posts about code review so if you haven’t checked it yet, maybe now is good time to do it.

But, if some of the previous steps are poorly done, especially the first one, then the code reviewer is not in a thankful position, because entire responsibility for code quality is now shifted towards him. First problem here is that the developer who raised the pull request probably does not understand the code he authored, and this later can produce more issues when it comes to unexpected exceptions or maintenance. The author’s name is attached to the commit, but they cannot confidently explain why parts of the implementation exist or how they work.

Looking at the entire AI movement in the past years, I see one alarming thing if this is not handled correctly. It goes in the direction where teams are producing code much faster then ever before, but in the same time, senior engineers increasingly spend their time reviewing and validating AI-generated changes rather than writing new implementations themselves. In that case, AI accelerates code generation without necessarily accelerating software delivery.

Takeaways and Conclusion

AI has definitely changed where engineering effort is spent. Writing the code is becoming increasingly automated, but understanding, validating, and maintaining that same code remain human responsibility. Teams that recognize this shift and adapt their review process accordingly can benefit far more from AI than those who focus solely on generating code faster. Over time, that code will become harder to maintain if not even impossible.

Most important lesson I have learned is to keep code amount per pull request as small as possible, because it is easier then for the developer to review it and also for the peer to take a look at it. Large pull requests help neither the author nor the reviewer. They just increase uncertainty and reduce the confidence in the delivered product.

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.

DEV Community: Mirnes

JWT Authentication in ASP.NET Core Web API: Access and Refresh Tokens

Design

Login

Authenticated Request

Authentication Flow

Controller

Service

Database

Middleware

Dependency Injection

How to Review Code in The Age of AI

Active Code Review By The Author

Automated Review

Code Review By Peer

Takeaways and Conclusion

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

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