CQRS is more of a data management thing rather than and doesn't tend to bleed too heavily into an application layer (or Domain if you prefer, as it tends to be most often used in DDD systems). Your MVC application, on the other hand, is a presentation layer application and should be fairly well separated from the query/persistence core of the CQRS.

Another thing worth noting (given your comparison of the default Login method and desire for thin controllers): I wouldn't exactly follow default ASP.NET templates/boilerplate code as being anything we should worry about for best practices.

I like thin controllers as well, because they're very easy to read. Each controller I have usually has a "service" object that it pairs with that essentially handles the logic required by the controller:

public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null) { var result = _service.Login(model); switch (result) { case result.lockout: return View("Lockout"); case result.ok: return RedirectToLocal(returnUrl); default: return View("GeneralError"); } } 

Still thin enough, but we've not really changed how the code works, just delegate the handling to the service method, which really serves no purpose other than making the controller actions easy to digest.

Bear in mind, this service class is still responsible for delegating the logic to the model/application as required, it's really just a slight extension of the controller to keep the code neat. The service methods are generally pretty short as well.

I'm not sure the mediator would be doing anything conceptually different than that: moving some basic controller logic out of the controller and into somewhere else to be processed.

(I hadn't heard of this MediatR before, and a quick look at the github page doesn't seem to indicate that it's anything groundbreaking - certainly not something like CQRS - in fact, it looks to be something like just another abstraction layer you can put in to complicate the code by means of making it look simplier, but that's just my initial take)

I highly recommend you view Jimmy Bogard's NDC presentation on his approach to modelling http requests https://www.youtube.com/watch?v=SUiWfhAhgQw

You will then get a clear idea of what Mediatr is used for.

Jimmy does not have a blind adherence to patterns and abstractions. He's very pragmatic. Mediatr does clean up controller actions. As for the exception handling, I push that into a parent class called something like Execute. So you end up with a very clean controller action.

Something like:

public bool Execute<T>(Func<T> messageFunction) { try { messageFunction(); return true; } catch (ValidationException exception) { Errors = string.Join(Environment.NewLine, exception.Errors.Select(e => e.ErrorMessage)); Logger.LogException(exception, "ValidationException caught in SiteController"); } catch (SiteException exception) { Errors = exception.Message; Logger.LogException(exception); } catch (DbEntityValidationException dbEntityValidationException) { // Retrieve the error messages as a list of strings. var errorMessages = dbEntityValidationException.EntityValidationErrors .SelectMany(x => x.ValidationErrors) .Select(x => x.ErrorMessage); // Join the list to a single string. var fullErrorMessage = string.Join("; ", errorMessages); // Combine the original exception message with the new one. var exceptionMessage = string.Concat(dbEntityValidationException.Message, " The validation errors are: ", fullErrorMessage); Logger.LogError(exceptionMessage); // Throw a new DbEntityValidationException with the improved exception message. throw new DbEntityValidationException(exceptionMessage, dbEntityValidationException.EntityValidationErrors); } catch (Exception exception) { Errors = "An error has occurred."; Logger.LogException(exception, "Exception caught in SiteController."); } // used to indicate that any transaction which may be in progress needs to be rolled back for this request. HttpContext.Items[UiConstants.Error] = true; Response.StatusCode = (int)HttpStatusCode.InternalServerError; // fail return false; } 

Usage looks a bit like this:

[Route("api/licence")] public IHttpActionResult Post(LicenceEditModel licenceEditModel) { var updateLicenceCommand = new UpdateLicenceCommand { LicenceEditModel = licenceEditModel }; int licenceId = -1; if (Execute(() => _mediator.Send(updateLicenceCommand))) { return JsonSuccess(licenceEditModel); } return JsonError(Errors); } 

Hope that helps.

Many people (I did it too) confuse pattern with a library. CQRS is a pattern but MediatR is a library that you can use to implement that pattern

You can use CQRS without MediatR or any in-process messaging library and you can use MediatR without CQRS:

public interface IProductsWriteService { void CreateProduct(CreateProductCommand createProductCommand); } public interface IProductsReadService { ProductDto QueryProduct(Guid guid); } 

CQS would look like this:

public interface IProductsService { void CreateProduct(CreateProductCommand createProductCommand); ProductDto QueryProduct(Guid guid); } 

In fact, you don't have to name your input models "Commands" like above CreateProductCommand. And input of your queries "Queries". Command and queries are methods, not models.

CQRS is about segregation of responsibility (read methods must be in a separate place from write methods - isolated). It's an extension to CQS but the difference is in CQS you can put these methods in 1 class. (no responsibility segregation, just command-query separation). See separation vs segregation

From https://martinfowler.com/bliki/CQRS.html:

At its heart is the notion that you can use a different model to update information than the model you use to read information.

There's confusion in what it says, it's not about having a separate model for input and output, it's about separation of responsibility.

CQRS and id generation limitation

There's one limitation you will face when using CQRS or CQS

Technically in the original description commands shouldn't return any value (void) which I find stupid because there's no easy way to get generated id from a newly created object: https://stackoverflow.com/questions/4361889/how-to-get-id-in-create-when-applying-cqrs.

so you have to generate id each time yourself instead of letting the database do it.

If you want to learn more: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf