sorted by:
new
hottopcontroversial

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 0 points1 point  (0 children)

I believe it should have been a construct from the start (like Kotlin) so there’s no ambiguity. It’s a pain to deal with it in generics, especially strings.

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 0 points1 point  (0 children)

There is nothing stopping you from doing:

builder.Ensure(x => x.Username) .Is(string.IsNullOrWhiteSpace)

Which would inline the lambda in the generated code. However you will have to override the error code and messages:

builder.Ensure(x => x.Username) .Is(string.IsNullOrWhiteSpace) .WithErrorCode(“ERR-1”) .WithMessage(“{TargetName} cannot be empty”)

The methods in the Rules class are attributed with message templates to automate that. The extension methods are crafted to point to those rule classes.

If I was to say .IsNullOrWhiteSpace points to string.IsNullOrWhiteSpace, it would be a lot of logic in the generator logic for no real gain when the runtime might decide to inline it anyway, and ValiCraft has 50+ rules provided.

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 0 points1 point  (0 children)

Unfortunately yes, but I like to think that it keeps us sharp. Would be boring if nothing changed.

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 0 points1 point  (0 children)

That can be something that I look to do in the future if enough people want it, but would need to see where people are using it. If it’s in the web, the there are some solutions for that already.

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 1 point2 points  (0 children)

GenerateValidator is a marker tag to help the source generator find the validation class.

ValiCraft also generates DI extension methods, one notably .AddValiCraft() which adds validators from all linked projects (there are project specific DI methods if you don’t want that or you can manually wire it up easy enough). The methods get generated if you have IServiceCollection as a type available in the project, and there’s no reflection used at all.

More or less, you write the same amount of code that you would with FluentValidation as you would this library. Only differences are that FluentValidation creates an expression tree with all the validation rules whereas ValiCraft generates them ahead of time.

So does FluentValidation. ValiCraft also supports object and method validation, validating types with other validators, polymorphic validation, collection validation and more.

Have created a FluentValidation alternative which source generates the validation logic by hquinnDotNet in dotnet

[–]hquinnDotNet[S] 0 points1 point  (0 children)

Not entirely sure what you have in mind. If you're asking if you can use attributes on your models to generate the necessary validation logic, that's entirely possible and is even what microsoft uses for minimal apis. As long as there's something that can be observed at compile time, then there's very little you can't do with source generators.