Обзор библиотеки FluentValidation. Часть 7.1. Встроенные валидаторы

[nkozhevnikov]

Чем эта статья (как и предыдущие) отличается от документации на сайте библиотеки? Кроме примеров.

[vludlss]

В первой части я писал, что серия статей называется обзорами, т. к. это не урок и неполноценный перевод документации. Как минимум на русском языке, больше примеров, иногда может рассматриваться то, чего нет в документации.

[vludlss]

Вы можете предложить как сделать следующие части лучше. Что-то добавить быть может?

[nkozhevnikov]

Я предлагаю в следующей статье показать ваш опыт с примерами применения этой библиотеки, а не переводить документацию с вашими комментариями.

Вот мне бы интересно было увидеть, например, следующее:

• Я хочу добавить валидацию, которая будет ходить глубоко в сервис (например, нам приспичило проверить какое-то поле на уникальность в базе). Как это можно сделать с FluentValidation?

• Как FluentValidation интегрировать с ASP.NET Core?

• У нас на проекте используются валидация с помощью атрибутов (RequiredAttribute, StringLengthAttribute, etc), которые отлично работают с ASP.NET Core. Можем ли мы распинать FluentValidation, чтобы он смотрел на атрибуты, а не писать валидаторы?

• К нам прилетел запрос, у которого есть Accept-Language в хедерах, и мы хотим отдать пользователю локализованное сообщение с ошибками валидации. Можно ли в этой истории распинать FluentValidation?

• Мы практикуем чистую архитектуру. Как в эту историю вписать FluentValidation?

• Зачем нам вообще нужен FluentValidation, если можно написать ещё один сервис, который будет валидировать модель?

[vludlss]

Интересные вопросы для отдельной статьи, не в рамках этой серии. Я не думаю, что стоит отказываться продолжать эту серию, это может быть полезно разработчикам уровнем по меньше чем у вас.

[vludlss]

Думаю что такая статья может выйти только после всех обзоров по библиотеке, как резюме. Сравнение FluentValidation с System.ComponentModel.DataAnnotations.

[Naf2000]

Есть валидаторы, компонующие другие валидаторы по and или or?

Есть валидатор, требующий выполнения при условии?

[vludlss]

Если я вас правильно понял, то ответы

На первый вопрос:

1. Объединение правил нескольких валидаторов, нацеленных на один и тот же тип модели: https://docs.fluentvalidation.net/en/latest/including-rules.html#

2. Можно выбрать конкретное свойство, которое должно быть провалидировано из всех, что описаны в валидаторе: https://docs.fluentvalidation.net/en/latest/specific-properties.html

3. Объединение правил в именованную группу, которую можно опционально вызывать при выполнении метода Validate: https://docs.fluentvalidation.net/en/latest/rulesets.html

На второй вопрос:
https://habr.com/ru/articles/799173/

https://docs.fluentvalidation.net/en/latest/dependentrules.html

https://docs.fluentvalidation.net/en/latest/cascade.html

[IosifLvovich]

public class NotNullValidator<T,TProperty> : PropertyValidator<T,TProperty>, INotNullValidator {

	public override string Name => "NotNullValidator";

	public override bool IsValid(ValidationContext<T> context, TProperty value) {
		return value != null;
	}

	protected override string GetDefaultMessageTemplate(string errorCode) {
		return Localized(errorCode, Name);
	}
}

Вот это вот != null может дать интересные результаты, если переопределить оператор !=

[mayorovp]

Не может, TProperty же не конкретный тип, а тип-параметр. к тому же без ограничения. Даже если у конкретного типа оператор перегружен - компилятор попросту не увидит его.

[ColdPhoenix]

Я боюсь, что если кто-то сделает подлянку с некорректным переопределением, то у вас в принципе будут проблемы.(+ пред коммент)

А вот будет ли warning при включённом null safety уже интереснее.

[Naf2000]

а зачем везде одинаково переопределять

protected override string GetDefaultMessageTemplate(string errorCode) { 	return Localized(errorCode, Name); } 

[barbarisanet]

Я могу видеть определенный смысл в формировании специализированных функций, скажем там, для проверки таких сущностей как email, credit-card, при проверке соответствия шаблону пароля...

Но видеть отдельным оператором такое как `LessThanOrEqual / GreaterThanOrEqual` или `ExclusiveBetween / InclusiveBetween` - мне лично прямо глаз режет.

Предлагаю в свободную минутку глянуть в сторону FlatValidator - всё то же самое, но выглядит попроще и работает побыстрее.

[vludlss]

Интересно было посмотреть, спасибо, не знал про такую.