DEV Community: Amandha Panagoda

MediatR + CQRS

Amandha Panagoda — Thu, 15 May 2025 17:57:18 +0000

You’ve probably seen it in many “clean architecture” diagrams: arrows pointing from Controllers to Handlers, from Handlers to Repositories, and this thing in the middle....MediatR. Paired with a buzzing acronym CQRS (Command Query Responsibility Segregation), it can feel like you’re building the next NASA control system when you just want to create a To-Do app.

But before you throw it all away as overengineering, let’s actually break it down. Because when used correctly, MediatR + CQRS can give your code: clear separation, testability, and fewer "what does this method even do?" moments.

What Is MediatR?

MediatR is a simple in-process messaging library for .NET, created by Jimmy Bogard. It helps you decouple your logic by acting as a mediator (get it?) between the request and the handler. Instead of calling a service directly, you send a request and let the handler handle it.

So instead of:

var result = _orderService.PlaceOrder(request);

You do:

var result = await _mediator.Send(new PlaceOrderCommand(request));

The MediatR tells the right handler to take over.

What Is CQRS?

CQRS stands for Command Query Responsibility Segregation. In simple terms: separate your read logic from your write logic. That’s it.

Commands mutate state. (PlaceOrderCommand, DeleteUserCommand)

Queries return data. (GetOrderByIdQuery, GetUsersListQuery)

In traditional CRUD apps, you have services like:

UserService.CreateUser();
UserService.GetUsers();

And when paired with MediatR, you get a smooth flow:

await _mediator.Send(new RegisterUserCommand(...));
var users = await _mediator.Send(new GetUsersQuery());

The benefit? You can optimize them independently. Queries can hit fast read replicas or return DTOs tailored for UI. Commands can enforce strict validation and business rules.

MediatR + CQRS

These two patterns play really well together. MediatR routes your commands and queries to the right handler. You end up with a codebase where:

The controller doesn’t know the details of business logic.
The logic is easily testable (you just test the handler).
The code is predictable and scalable.

But Do You Need It?

Here’s the catch: this combo isn’t free. You’ll be creating lots of files - commands, queries, handlers. Don’t use CQRS and MediatR unless you really need them.

When it makes sense:

You have complex domains with deep business logic.
You need clear audit trails, validations, and handler pipelines.
Your system is growing fast, and maintainability is key.
You’re writing unit-test-heavy applications and value isolation.

When it’s overkill:

It’s a simple CRUD app.
You have a tight deadline and limited devs.
You’re building a proof of concept or internal tool.

There’s no shame in keeping things simple.

Creating a Simple Project

Let’s walk through how to structure a simple .NET Web API project using CQRS with MediatR. We'll build a small app that manages Pokémon data.

Model

We start with a basic model to represent Pokémon data:

public class PokemonModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Generation { get; set; }
}

Data Access

We create an interface and its implementation to simulate a data store. This acts as our data access abstraction:

public interface IDemoDataAccess
{
    List<PokemonModel> GetPokemons();
    PokemonModel InsertPokemon(string name, string generation);
}

public class DemoDataAccess : IDemoDataAccess
{
    private List<PokemonModel> pokemons = new()
    {
        new PokemonModel { Id = 1, Name = "Bulbasaur", Generation = "Kanto" },
        new PokemonModel { Id = 2, Name = "Azurill", Generation = "Hoenn" }
    };

    public List<PokemonModel> GetPokemons() => pokemons;

    public PokemonModel InsertPokemon(string name, string generation)
    {
        int newId = pokemons.Max(p => p.Id) + 1;
        var pokemon = new PokemonModel { Id = newId, Name = name, Generation = generation };
        pokemons.Add(pokemon);
        return pokemon;
    }
}

Queries

In CQRS, we separate reads (queries) from writes (commands).

And Queries are used for reading data only — no changes allowed.

public record GetPokemonListQuery : IRequest<List<PokemonModel>> { }

public record GetPokemonByIdQuery(int id) : IRequest<PokemonModel> { }

Commands

Used for write operations like creating or updating data.

public record InsertPokemonCommand(string Name, string Generation) : IRequest<PokemonModel> { }

Handlers

Handlers are where the real logic happens. MediatR finds the right handler based on the request sent.

Get List

public class GetPokemonListHandler : IRequestHandler<GetPokemonListQuery, List<PokemonModel>>
{
    private readonly IDemoDataAccess _data;

    public GetPokemonListHandler(IDemoDataAccess data)
    {
        _data = data;
    }

    public Task<List<PokemonModel>> Handle(GetPokemonListQuery request, CancellationToken cancellationToken)
    {
        return Task.FromResult(_data.GetPokemons());
    }
}

Get By Id

public class GetPokemonByIdHandler : IRequestHandler<GetPokemonByIdQuery, PokemonModel>
{
    private readonly IMediator _mediator;

    public GetPokemonByIdHandler(IMediator mediator)
    {
        _mediator = mediator;
    }

    public async Task<PokemonModel> Handle(GetPokemonByIdQuery request, CancellationToken cancellationToken)
    {
        var pokemons = await _mediator.Send(new GetPokemonListQuery());
        return pokemons.FirstOrDefault(x => x.Id == request.id);
    }
}

Insert

public class InsertPokemonHandler : IRequestHandler<InsertPokemonCommand, PokemonModel>
{
    private readonly IDemoDataAccess _data;

    public InsertPokemonHandler(IDemoDataAccess data)
    {
        _data = data;
    }

    public Task<PokemonModel> Handle(InsertPokemonCommand request, CancellationToken cancellationToken)
    {
        return Task.FromResult(_data.InsertPokemon(request.Name, request.Generation));
    }
}

API Layer

The controller sends requests to MediatR, which then delegates to the appropriate handler.

[ApiController]
[Route("api/[controller]")]
public class PokemonController : ControllerBase
{
    private readonly IMediator _mediator;

    public PokemonController(IMediator mediator)
    {
        _mediator = mediator;
    }

    [HttpGet]
    public async Task<List<PokemonModel>> GetPokemon()
    {
        return await _mediator.Send(new GetPokemonListQuery());
    }

    [HttpGet("{id}")]
    public async Task<PokemonModel> GetPokemonById(int id)
    {
        return await _mediator.Send(new GetPokemonByIdQuery(id));
    }

    [HttpPost]
    public async Task<PokemonModel> Post([FromBody] PokemonModel pokemon)
    {
        return await _mediator.Send(new InsertPokemonCommand(pokemon.Name, pokemon.Generation));
    }
}

How CQRS and MediatR Work Together

Separation of Concerns: Queries (GetPokemonListQuery) are for reading. Commands (InsertPokemonCommand) are for writing.
Request/Response Pattern: Each query or command implements IRequest<T>, and is handled by IRequestHandler<TRequest, TResponse>.
MediatR Acts as a Mediator: IMediator.Send() sends requests to their correct handlers. The controller doesn’t need to know who handles what, it just sends the request.

Final Thoughts

MediatR and CQRS are amazing tools. Used right, they bring order to the chaos of growing applications. But like any tool, they’re not a requirement.

Don’t feel pressured to adopt them just because it looks cleaner.

Yes, clean code is great. But pragmatic code is even better.

Start simple. Let your architecture evolve with your app. Reach for CQRS and MediatR when your business logic cries out for structure, not just because the latest YouTube video told you so.

The best architecture is the one you understand, maintain, and scale comfortably.

How to Train Your Model When Data Lies

Amandha Panagoda — Fri, 28 Feb 2025 15:37:54 +0000

Imagine you're learning to tell dog breeds apart, but your teacher occasionally tells you the wrong information. They sometimes mistakenly call a Labrador a Golden Retriever. They also call a Husky a Malamute at times. When this keeps happening, you'll start doubting yourself, or worse....learn the wrong things altogether.

This is exactly what happens when you train machine learning models on noisy labels. Labels that are erroneous in the data. The model gets confused, learns the incorrect patterns, and does not predict well.

So, how do you make a model smart enough to handle these errors? That's what we will explore in this article.

You can find the code snippets I've used here in my colab notebook: Colab Notebook

What Are Noisy Labels?

A label is the correct answer for a data point. So, if you have a data set of pictures of cats and dogs, each picture will have a label of "cat" or "dog."

But sometimes, labels are wrong. This can happen because:

Humans make errors: Someone manually labeled a picture of a Husky as a Wolf.
Data can be unclear: Some flowers are nearly identical to each other.
Automatic labeling goes wrong: A weak system can incorrectly classify objects.

These types of errors in labels are what are called noisy labels. And if you train a model with too much noise, it may end up memorizing the mistakes instead of learning from correct patterns.

Let’s Create a Noisy Dataset in Python

First, let’s generate a clean dataset, then introduce some noise.

Step 1: Generate a Clean Dataset

We’ll create a simple dataset with two classes (0 and 1) using sklearn.datasets.make_classification.

import numpy as np
import matplotlib.pyplot as plt
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split

# Create a classification dataset with 1000 samples (data points) and 2 features (columns)
# n_informative=2 means the two features are useful for the classification task
# n_redundant=0 means no extra, redundant features are added
X, y = make_classification(n_samples=1000, n_features=2, n_informative=2, 
                           n_redundant=0, n_clusters_per_class=1, random_state=42)


X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

plt.scatter(X_train[:, 0], X_train[:, 1], c=y_train, cmap="coolwarm", alpha=0.7)
plt.title("Clean Dataset")
plt.show()

Step 2: Add Noisy Labels

Now, we introduce 20% label noise by flipping some labels randomly.

def add_label_noise(y, noise_rate=0.2):
    np.random.seed(42)
    num_noisy = int(len(y) * noise_rate)
    noisy_indices = np.random.choice(len(y), num_noisy, replace=False)
    y_noisy = y.copy()

    y_noisy[noisy_indices] = 1 - y_noisy[noisy_indices] # flip the labels :)
    return y_noisy

# Introduce noise into labels
y_train_noisy = add_label_noise(y_train, noise_rate=0.2)

plt.scatter(X_train[:, 0], X_train[:, 1], c=y_train_noisy, cmap="coolwarm", alpha=0.7)
plt.title("Dataset with Noisy Labels (20% incorrect)")
plt.show()

🔴 Notice the difference? Some red points are mixed into the blue area and vice versa. That’s the noise!

Why Are Noisy Labels Bad?

To understand why it can be a problem, let’s train a Random Forest model on both clean and noisy datasets to compare how noise affects accuracy.

from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score

# Train on the clean labels
clf_clean = RandomForestClassifier(random_state=42)
clf_clean.fit(X_train, y_train)
acc_clean = accuracy_score(y_test, clf_clean.predict(X_test))

# Train on noisy labels
clf_noisy = RandomForestClassifier(random_state=42)
clf_noisy.fit(X_train, y_train_noisy)
acc_noisy = accuracy_score(y_test, clf_noisy.predict(X_test))

print(f"Accuracy with Clean Labels: {acc_clean * 100:.2f}%")
print(f"Accuracy with Noisy Labels: {acc_noisy * 100:.2f}%")

Accuracy with Clean Labels: 93.00%
Accuracy with Noisy Labels: 86.00% 😧

📉 On clean labels, the model was 93% accurate, yet when noisy labels were introduced, the accuracy dropped to 86%. This demonstrates the extent to which incorrect data can confuse a model during training.

This may not seem like a lot, but even a small proportion of noisy data (20% in this case) can lead to an apparent degradation in performance. This is because the model starts memorizing the incorrect labels instead of learning real patterns.

How to Handle Noisy Labels?

Method 1: Use a Smarter Loss Function (MAE Instead of Cross-Entropy)

As per my research in Google and ChatGPT, the most common loss function for classification is cross-entropy loss, but it overreacts to wrong labels. A better option is Mean Absolute Error (MAE), which is more resistant to noise.

import tensorflow as tf
from tensorflow.keras.models import Sequential
from tensorflow.keras.layers import Dense

model = Sequential([
    Dense(16, activation="relu", input_shape=(2,)),
    Dense(16, activation="relu"),
    Dense(1, activation="sigmoid")
])

model.compile(optimizer="adam", loss="mean_absolute_error", metrics=["accuracy"])

model.fit(X_train, y_train_noisy, epochs=20, batch_size=16, verbose=0, validation_data=(X_test, y_test))

_, acc = model.evaluate(X_test, y_test)
print(f"Accuracy with MAE loss: {acc:.4f}")

MAE gives less importance to extreme errors, making the model less likely to overfit to noisy labels.

Accuracy with MAE loss: 0.9150

Method 2: Co-Teaching (Two Models Teach Each Other)

Instead of using one model, we can train two models and let them filter out the noisy data for each other.

from sklearn.linear_model import LogisticRegression

model1 = LogisticRegression() 
model2 = LogisticRegression()

# Identify "trusted" samples (least noisy)
trusted_samples = np.abs(y_train - y_train_noisy) < 0.5

model1.fit(X_train[trusted_samples], y_train_noisy[trusted_samples])
model2.fit(X_train[trusted_samples], y_train_noisy[trusted_samples])

# Combine predictions
preds1 = model1.predict(X_test)
preds2 = model2.predict(X_test)
final_preds = (preds1 + preds2) // 2  # Majority voting

acc_coteach = accuracy_score(y_test, final_preds)
print(f"Accuracy with Co-Teaching: {acc_coteach:.4f}")

Each model trains only on "trusted" data, preventing them from memorizing noise.

Accuracy with Co-Teaching: 0.9000

Method 3: Semi-Supervised Learning (Train on Clean Data First)

If we have some clean data, we can train the model on it first, then use it to fix noisy labels.

# Train model on clean samples
model_clean = RandomForestClassifier()
model_clean.fit(X_train[trusted_samples], y_train_noisy[trusted_samples])

y_train_fixed = model_clean.predict(X_train)

final_model = RandomForestClassifier()
final_model.fit(X_train, y_train_fixed)

acc_fixed = accuracy_score(y_test, final_model.predict(X_test))
print(f"Accuracy after Semi-Supervised Learning: {acc_fixed:.4f}")

The model learns correct patterns first, then refines its understanding with the full dataset.

Accuracy after Semi-Supervised Learning: 0.9050

Conclusion

While noisy labels cause a noticeable drop in performance, techniques like Semi-Supervised Learning and MAE loss can help recover some of the lost accuracy, though nothing quite matches the performance of clean data.

[Boost]

Amandha Panagoda — Thu, 26 Dec 2024 06:46:48 +0000

The Art of Game Testing

Amandha Panagoda ・ Dec 26

#gamedev #testing

The Art of Game Testing

Amandha Panagoda — Thu, 26 Dec 2024 05:50:50 +0000

When we think of software quality assurance, the image that comes to mind often includes endless test cases, defect logs, and late-night debugging. At its core, QA ensures that a product fulfills its purpose without compromise. While this principle applies universally, game testing elevates QA to a whole new level. Because games are more than just software; they’re immersive experiences crafted to captivate, challenge, and entertain.

Understanding Game Components

Before diving into testing, it’s essential to understand the intricate anatomy of a game. Games are like fine tuned machine; every part must work in harmony.

1. Menu and UI
Testing menus isn’t just about clicking buttons; it’s about usability, responsiveness, and accessibility. Can players navigate seamlessly using a controller, keyboard, or mouse?

2. Art and Animation
From textures to character movement, visuals need to render flawlessly across all supported platforms. Testers test edge cases, like extreme camera angles or lag spikes during animations.

3. Sound Design
Audio must sync perfectly with in-game actions. A gunshot sound should fire instantly, not 2 seconds later.

4. Music
Dynamic background music must transition seamlessly between scenarios. Abrupt stops and loops in audio will disrupt immersion.

5. Camera Controls
Ensure intuitive control while maintaining immersion, whether it’s a cinematic zoom or a free-roaming camera.

6. Player and Action Attributes
Character stats, weapon mechanics, and physics all need precise tuning. Have you ever seen a character unintentionally fly due to a physics glitch? Exactly.

7. World/Level/Scene
Test the boundaries of the game world. Can players walk through walls? Are there “invisible death traps”?

8. Triggers and Events
Ensure environmental interactions (like opening doors or triggering puzzles) function as intended. Misfires can ruin the gameplay flow.

9. Scoring and Progression
Gameplay progression, such as leveling up or unlocking items, must be error-free and balanced. Testers often collaborate closely with designers here.

Types of Game Testing

Game QA involves a variety of testing approaches, each tailored to ensure every component works flawlessly.

1. Combinatorial Testing
This involves testing different combinations of game settings (e.g., resolutions, hardware configurations, or gameplay paths).
Usually done using automation tools.

2. Functionality Testing
The bread-and-butter of QA. Verify mechanics, ensure controls are responsive, and document every test scenario with expected vs. actual behavior.

3. Compatibility Testing
Games must perform well across multiple platforms (PC, console, mobile). Testing isn’t just about resolution but also input methods like controllers, keyboards, and touchscreens.

4. Regression Testing
Fixing a bug might inadvertently break other areas. Testers must meticulously re-check related functionalities.

5. Ad Hoc Testing
Sometimes, the best bugs are discovered through unscripted exploration. Play like an over-curious player trying to break the game.

6. Load Testing
Can the game’s servers handle 10,000 players? What about 50,000? Simulated load tests measure server thresholds.

7. Play Testing
Focus on gameplay balance, difficulty levels, and overall player experience.

8. Soak Testing
Leave the game running for hours (or even days) to identify long-term stability issues like memory leaks or crashes.

9. Alpha and Beta Testing
Alpha tests involve internal testers, while beta tests allow external players to catch bugs and provide valuable feedback.

Game Testing Practices

1. Boundary and Glitch Explorations
Players love pushing limits. This is why testers explore:

Jumping off high points with unusual combos.
Walking along map edges or corners.
Opening multiple menus mid-action to trigger unexpected behaviors.

2. Latency Testing for Controls
In fast-paced games like first-person shooters, every millisecond counts. Use tools to measure input-to-action latency, ensuring not just functionality but speed.

3. Save and Load Exploits
Games often fail due to improper handling of save/load mechanics:

Save mid-action (e.g., mid-jump) and reload.
Corrupt save files to test error handling.

4. AI Behavior Analysis (edge cases are critical here)

How AI responds to erratic player behavior (e.g., running in circles).
Situations where multiple AI units get stuck in confined spaces.

5. Environment Manipulation
For destructible environments, verify chain reactions. For example, does breaking one object affect others nearby? Sync damage effects with animations.

6. Peripheral Testing
Console games need to support various controllers, steering wheels, VR headsets, and even third-party devices.

7. Localization Testing
For global audiences, text rendering must be spot-on:

Does German text (typically longer) fit in menus?
Do right-to-left scripts (like Arabic) render correctly?

The Human Touch in Game Testing

Games are about more than just technical precision; they’re about fun. While rigorous testing ensures functionality, testers must also assess emotional responses:

Is the game intuitive?
Does it feel rewarding to progress?
Are players likely to get frustrated by specific mechanics?

Sometimes, the best QA isn’t about catching bugs; it’s about making sure the game feels right.

Conclusion

Game testing is a blend of technical rigor and creative exploration. It demands the mindset of both a developer and a player. Beyond ensuring flawless execution, it’s about enabling players to immerse themselves in uninterrupted joy.

So, the next time you boot up a game and enjoy a seamless experience, remember the testers who meticulously checked every jump, trigger, and sound bite to make that moment possible.🙂‍↕️