[Bug] Performance issues with complex models

[dmorawetz]

Using the code from #205, we experience serious performance issues, making this package unusable for us.

We have hundreds of fields in our model with lists of more complex models. Because our form is user-configurable, we have effectively a tree of those complex models. We suspect the performance of PropertyPathHelper.ToFluentPropertyPath to be the problem.

We use this package since 2021 and had never issues with the default MemberNameValidatorSelector.

Concerning the original issue from https://github.com/Blazored/FluentValidation/issues/204, I think there should be a better way to select the validator of the root model, if needed. It should at least be configurable, as for our project, the previous selection strategy worked better.

It seems like a difficult problem, though, considering #235, #76, and #104.

[pwelter34]

Thanks for input. In the new year I'll take on reworking the whole property resolution issues.

[psampaio]

One thing to look out for is recursion in non-primitive properties, in particular Guid. From my basic exploration, #204 is including static properties, which means that it will get stuck on Guid.NewGuid().

[Albiniivari]

We have the same issue. Noticed that when our model has a collection of objects, and those objects have datetime/string, the PropertyPathHelper.ToFluentPropertyPath goes into an infinite-loop of adding different nodes to check. It also seemed to add every character of a string as a node to check (because string implement IEnumerable).

[teneko]

@Albiniivari Recursion is not supported scenario by ToFluentPropertyPath. Interestingly, the "root" model is actually intended to crawl through child properties—and their children—to find the one that matches the field identifier model. I get the idea, but it's approached the wrong way around. There are two possible approaches:

1. Let the consumer describe the path starting from EditContext.Model.
2. Make the validator component nestable, allowing it to handle sub-models by branching the root EditContext. The branched EditContext would manage the sub-model and let validation errors bubble up to the root EditContext. I implemented both approaches, because I was curious how far I could stretch the great implementation design decisions of EditContext.

Let me know if you have any questions regarding the approaches, @pwelter34.

[megafetis]

One thing to look out for is recursion in non-primitive properties, in particular Guid. From my basic exploration, #204 is including static properties, which means that it will get stuck on Guid.NewGuid().

For me, infinite-loop with Guid property, when algorithm tries to handle static property Guid.AllBitsSet. I have to use a modified source code with additional conditions .GetProperties(BindingFlags.Public | BindingFlags.Instance) to avoid this problem