The validator does not work with collection arguments
See original GitHub issueConsider this validator
public class FooValidator : AbstractValidator<Foo>
{
public FooValidator()
{
RuleFor(foo => foo.Bar)
.NotEmpty()
.NotNull();
}
}
And this action method
[HttpPost]
public Task Foobar([FromBody]IEnumerable<Foo> foo)
{
}
The library fails to validate
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
The validator does not work with collection arguments #1056
Create a validator that inherits from AbstractValidator<IEnumerable<Foo>> , which should then be invoked for the parameter. Internally it can ...
Read more >Spring validation keeps validating the wrong argument
Validation generally will only work for model attributes or request bodies not for other objects. You will have to put it in your...
Read more >Model validation in ASP.NET Core MVC and Razor Pages
Model validation occurs after model binding and reports errors where data doesn't conform to business rules. For example, a 0 is entered in ......
Read more >Hibernate Validator 8.0.1.Final - Jakarta Bean ...
When applying constraints on an Iterable type argument, Hibernate Validator will validate each element. Example 2.3, “Container element ...
Read more >Active Record Validations
Active Record ValidationsThis guide teaches you how to validate the state of objects before they go into the database using Active Record's validations ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Actually that functionality is already in place but not released yet. Coming in 8.2. You’ll be able to retrieve the service provider from the context (in asp.net core projects), and there are some shortcut methods for retrieving validators.
Regarding singletons: yes there is a performance benefit from caching, but it’s not huge. The expensive part is compiling the rule lambda expressions to delegates, but we already perform separate caching for this. You can of course register validators as singleton if you prefer, but I found that back when this used to be the default it created a huge amount of confusion for developers who didn’t understand the implications of dependency lifetimes, so defaulting to transient is the path of least resistance.
Downside is you need to run your rule mapping everytime. A singleton could have been cached. Probably not a problem for our models though. Yes, I ment that with “Ah it seems the validator is registered transient, so I can use constructor injection.”. Since its a transient scope I can use constrtor injection instead of service locator pattern. Though a custom locator pattern for the context would have been pretty ok. Then you can benefit from singleton caching of the rules. Like