Why should you care?

ShopNest controllers stay thin — they send PlaceOrderCommand instead of injecting five services.

See it live — copy this example

Paste into a C# console or class library project and run dotnet run.

// Concept aligned with MediatR shapes
public interface IRequest<T> { }
public sealed record PlaceOrderCommand(string Sku) : IRequest<Guid>;
public interface IRequestHandler<TRequest, TResponse> where TRequest : IRequest<TResponse>
{
    Task<TResponse> Handle(TRequest request);
}
public sealed class PlaceOrderHandler : IRequestHandler<PlaceOrderCommand, Guid>
{
    public Task<Guid> Handle(PlaceOrderCommand request)
    {
        var id = Guid.NewGuid();
        Console.WriteLine($"placed {request.Sku} -> {id}");
        return Task.FromResult(id);
    }
}

// await mediator.Send(new PlaceOrderCommand("HD-100"));
Console.WriteLine(await new PlaceOrderHandler().Handle(new PlaceOrderCommand("HD-100")));

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• One command → one handler.
• Controllers depend on IMediator.
• Pipeline behaviors (logging/validation) wrap handlers in a later lesson.

Practice next

1. Run the handler sample.
2. Add MediatR package in a real Web API.
3. Send from a minimal endpoint.
4. Return a result record instead of Guid.
5. Add INotification for OrderPlaced.

Remember

IRequest + handler. Thin controllers. Behaviors for cross-cutting.

ShopNest MediatR commands

POST /orders sends PlaceOrderCommand.

Outcome: Endpoint code stays tiny and consistent.