MediatR and CQRS Pattern | Software Architecture 101

The goal of this blog post is simple..

First, we talk about CQRS software pattern and its use cases… why it is so damn important to have a decoupled application achieved by the CQRS Pattern.Then we’ll dive into what MediatR is and what it can do…

CQRS Pattern

This image below explains about two models within the Application layer, which is the Query and Command model.

The Front-End UI communicates with these models to create, update, safe and receive data from the Database.

Why CQRS?

Single Responsibility 

Single Responsibility is a computer programming principle. It states that every module or class should have responsibility for a single part of the functionality provided by the software. Therefore, all entities are each a Single Responsibility.

Benefits of Single Responsibility:

1.  It makes it easier to edit and add functionality to a class/model that has a single responsibility 
2. Will achieve loosely coupled application
3. Independent of framework
4. Code is more readable and understandable

This is how I segregate the
Command and Query Responsibility Segregation pattern

[ApplicationName].Core.Application

As you can see above, I have a Customers folder and inside that folder contains the commands, models, queries, and validators.

For example in my case, I have a “CreateCustomerCommand.cs'” and “CreateCustomerCommandHandler” in the Commands folder. I also have “get” classes which are structured similarly in naming convention; “GetAllCustomersQuery.cs” and “GetAllCustomersQueryHandler.cs“.

The Commands are for Creating, Updating and Deleting objects/entities. The queries are for searching and getting data back out from the database.

An entity, is basically a “thing“. It can be anything . An entity could be a customer, a book or a coffee.

Entity definition for the haters

MediatR – Jimmy Bogard

So this guy Jimmy did a great job on implementing a library for the function of CQRS pattern. Benefits include:

• Simple mediator implementation in .NET

• In-process messaging with no dependencies.

• Supports request/response, commands, queries, notifications and events, synchronous and async with intelligent dispatching via C# generic variance.

• Any block can opt into these alignments. The embed block has them also, and is responsive out of the box:

Using MediatR in ASP.Net Core was slightly tricky, not many out there with the correct implementation. It actually is very simple, but it took me some time to figure it all out. (I’m not a newbie in the .NET Framework)

Here is some code for in the StartUp.cs class you can use to register the MediatR service:

See what I did there uptop, I registered the Command and the Command Handler

Don’t forget to do this!

The controllers in the MVC model will reference these commands, queries. 

The beauty is that MediatR handles the requests in the pipeline.

A “CreateCustomerCommand.cs” implementation:

namespace QAEngine.Application.Customers.Command
{
  public class CreateCustomerCommand : IRequest
  {
    public string Id { get; set; }
    public string Title { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string Region { get; set; }
    public string PostalCode { get; set; }
    public string Country { get; set; }
    public string Phone { get; set; }
    public DateTime AccountCreated { get; set; }
    public DateTime DateOfBirth { get; set; }
  }
}

A “CreateCustomerCommandHandler.cs” implementation:

namespace QAEngine.Application.Customers.Command
{
 public class CreateCustomerCommandHandler : IRequestHandler
 {
   private readonly QAEngineDbContext _context;  
   public CreateCustomerCommandHandler(QAEngineDbContext context)
   {
     _context = context;
   }

    public async Task<CustomerModel> Handle(CreateCustomerCommand 
    request, CancellationToken cancellationToken)
    {
        var entity = new Customer
        {
            CustomerId = request.Id,
            Title = request.Title,
            FirstName = request.FirstName,
            LastName = request.LastName,
            Address = request.Address,
            City = request.City,
            Region = request.Region,
            PostalCode = request.PostalCode,
            Country = request.Country,
            Phone = request.Phone,
            AccountCreated = request.AccountCreated,
            DateOfBirth = request.DateOfBirth.Date
        };

        _context.Customers.Add(entity);
        await _context.SaveChangesAsync(cancellationToken);
        return CustomerModel.Create(entity);
    }
  }
}

Finally, Here is my Customer controller, where I utilise these beautiful implementations <3

    [HttpGet()]
    public Task<List<CustomerListModel>> ViewCustomers()
    {
        return Mediator.Send(new GetCustomerListQuery());
    }


    [HttpGet("{id}")]
    public async Task<IActionResult> FindACustomer(string id)
    {
        return Ok(await Mediator.Send(new GetCustomerModelQuery { Id = id }));
    }


    [Authorize]
    public IActionResult NewCustomer()
    {

        return View();
    }

    [Authorize]
    [HttpPost]
    //noteToSelf = FromForm means from the bloody form not [FromBody]
    public async Task<IActionResult> NewCustomer([FromForm]CreateCustomerCommand command)
    {


        return Ok(await Mediator.Send(command));

    }

    [HttpPut("{id}")]
    public async Task<IActionResult> UpdateCustomerDetails(string id, [FromBody]UpdateCustomerCommand command)
    {
        if (command == null || command.Id != id)
        {
            return BadRequest();
        }


        return Ok(await Mediator.Send(command));
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteCustomer(string id)
    {
        await Mediator.Send(new DeleteCustomerCommand { Id = id });
        return NoContent();
    }

Read my journey: https://www.bilaalsblog.com/pilot-a-software-developers-journey-and-the-amount-of-coffees-consumed/