CQRS Validation With MediatR and FluentValidation in ASP.NET Core Web API

►► Master Web API development Best Practices: bit.ly/3TnqoFQ
►► Build great web apps in Blazor WebAssembly: bit.ly/437g87T
►► Support us on Patreon and get the source code: / codemaze
In this video, you will learn how to implement validation using FluentValidtaion with CQRS and MediatR in the ASP.NET Core Web API application.
Often when we build applications, we have many cross-cutting concerns. These include authorization, validating, and logging.
Instead of repeating this logic throughout our handlers, we can use Behaviors. Behaviors are very similar to ASP.NET Core middleware. They accept a request, perform some action, and then (optionally) pass along the request.
So, let’s get to work to see how we can use behaviors for the validation logic.
LINKS MENTIONED IN THE VIDEO
►► CQRS and Mediatr Queries - • CQRS And MediatR in AS...
►► CQRS and Mediatr Commands - • CQRS And MediatR In AS...
►► Problem Details - • How to Use the Problem...
FOLLOW US ON SOCIAL MEDIA!
►► / marinko-spasojevic
►► / codemazeblog
►► / codemazeblog

[@CodeMaze]

Thank you all for watching and for your support. ►► If you want to master Web API development using best practices, check out our Web API book: bit.ly/3x75ZMM ►► Also, to build great full-stack apps with Blazor, check out our course: bit.ly/3Pw3Y33

[@abdullrhmanelhelw5162]

What I can say to all of you is thanks. In the last 3 months, I started studying CQRS, and it was very difficult, but when you started the CQRS video series, all the difficulties turned into ease. Thanks! I hope you start a new series titled Domain Driven Design.

[@CodeMaze]

Thank you to for the kind words. It means a lot to me. Also, thank you for the support and watching the videos.

[@andresbeltran5779]

Excellent video, I will try to implement this solution in my projects. I just have one question, at the handler level, shouldn't something be implemented or just regular stuff? Is it enough to define the pipeline behavior and the type of input and output data to the pipeline recognize the type of the request and enter in to that flow? How does the pipeline know if there is a validator? by the syntax of the created class that must end in validator or is it a kind of relationship that is established with fluent validation and mediatr behind? Thank you so much.

[@CodeMaze]

Hi. You don't have to add anything to the handler. It has nothing to do with the validation. All you have to do is create a validator class that inherits from the AbstractValidator where T is the command you are validating, and apply the validation rules. The rest is on the Pipeline level.

[@andresbeltran5779]

@@CodeMaze got it thx

[@elpe21]

Well, a bit shame the example is so simple and for example do not cover if product already exists within some data-store. Also, throwing example is not the way things should be done

[@CodeMaze]

Hi. First of all, thank you for watching the video and your comment. Now, regarding the simplicity of the example, I always believe that it is the best source for learning if it is simple enough and still explains the feature well. That said, if a product already exists in a db, that has nothing to do with this validation. This is the handler's job to verify and return a proper response. About a throwing example - I completely disagree. It is the great way of doing things. It is easy to follow, it is in a single place, with a global handler easy to debug, doesn't show nothing more than it needs to show to the client... so as I said, a perfect solution. Of course if you think otherwise, feel free to use a response pattern or any similar one, but again, I strongly disagree that this is not the way things should be done - just as opposite.

[@elpe21]

@@CodeMaze throwing exceptions is very slow. So agree to disagree. Yes, simple example is good , however plenty of validation needs to be done with async so it would be nice to include it. kzbin.info/www/bejne/l2LclmybfLl1b5o

[@CodeMaze]

Hi. I am aware of that video and any others talking about exceptions, just one issue in all of them. They all assume you will return 15,000 responses with exceptions - well this is what was tested in this video as well as in any others. However, this is not the case in a production app. You will have this exceptional case maybe once in 1000 requests (if even that) and in that case, you won't even notice the difference which is literally a few milliseconds. I did my tests with production apps and wrote about that situation in our API book. So yes, exceptions are slower if you assume you will return them in a 1000 request one after the other, but if that's the case, you shouldn't be using exceptions at all and something is very wrong with your app structure. Also if you simply check the comments on the video you shared, you will see what the great majority of people think about exceptions and about using these other approaches in big production apps. Anyway, as you said, we disagree on this matter, and I perfectly respect that. Just it is not ok to tell someone that "something is not the way it should be done" - if you don't want to do it this way, don't do it, it is that simple.