Inject Abstract Validator class for Application Logic Validation in Endpoint.

[SViradiya-MarutiTech]

I am integrating fast-endpoints in my existing minimal .net 6 Application which implements mediatr Pattern, As per https://fast-endpoints.com/docs/validation#request-dto-validation, It seems it is possible to validate Dto only.

In Mediator Pattern we create Command Model from Request Dto, which contains Properties populated from Database(Like userStatus) and before calling Command Handler, all Abstract Validators are executed.

POST {user_id}/post/{post_id}
{
   "comment":"This is comment for post"
}

• 1) Minimal API Endpoint is called
• 2) Request Dto is mapped to Command
• 3) Mediatr Send command is called
• 4) Validation Pipeline is called.
• 5) Abstract Validator Class is executed.
  • Request Validation is for comment is valid
  • BusinessValidation is for post exists in database(404) and user status is active both values are fetched from database for fluent validation.

AbstractValidator Class

public class UserPostValidator : AbstractValidator<AddPostCommand>
    {
        private readonly IUserRepository _userRepo;
        private readonly IPostRepository _postRepo;
        public UserPostValidator (IUserRepository  userRepo, IPostRepository postRepo )
        {
                _userRepo = userRepo;
                 _postRepo = postRepo;
                //Validation

        }
    }

Q1: So in fast endpoints is there any way to use existing Abstract Validation in Endpoint and validate Logic in one line. Q2: I believe builder.Services.AddFastEndpoints(o => o.IncludeAbstractValidators = true); will register existing AbstractValidator classes.

[dj-nitehawk]

one of the goals of fastendpoints is to eliminate the need for mediatr library. so ideally you shouldn't use mediatr with FE. here's a nice article why mediatr is a bad choice and why it's now losing popularity.

with FE, mediatr it's just an unneeded additional layer of complexity/indirection which makes it harder to maintain projects in the longrun. so my advise is to just use the REPR pattern. request dto -> endpont -> response dto. here's an introductory article i wrote.

and in cases where the endpoint handler becomes too large/complex, just extract that logic into a service and inject it. or use simple abstraction techniques to improve readability of the code for whoever needs to maintain the project in 5 yrs time.

so to answer your questions...

typically we use Validator<TRequestDto> to validate the incoming request dto, where the registration and the validator execution is all taken care of by FE.

yes you can use AbstractValidator<TRequestDto> instead of the above, by enabling that startup config setting o.IncludeAbstractValidators = true.

but... all that automatic goodness is only for validating the request dto classes in endpoints.

if you wanna use AbstractValidator<T> for anything else, you can, as you would normally do. but FE is not going to do anything to help you for that. just register them in DI yourself however you wish and inject them into your endpoints/services, and call validator.ValidateAsync(...) yourself.

hope i got the point across...

[SViradiya-MarutiTech]

Thanks, It will be helpful provide example, and document it, so other can also use this approach.