Да, ваш текущий подход не велик, и это именно тот сценарий, для которого был создан FluentValidator .
Например, в одном из наших объектов у нас есть некоторая проверка PostCode, которая требует сложных правил, чтобы определить, действителен ли почтовый индекс, поэтому мы делаем что-то вроде этого:
public class AddressValidator : AbstractValidator<Address>
{
private readonly IPostCodeRepository _postcodeRepo;
public AddressValidator(IPostCodeRepository postcodeRepo)
{
_postcodeRepo = postcodeRepo;
RuleFor(a => a.Postcode)
.NotEmpty()
.WithMessage("Postcode is required")
.Must(BeValidPostcodeSuburbStateCombo)
.WithMessage("Postcode is not valid for this state");
}
private bool BeValidPostcodeSuburbStateCombo(Address model, string property)
{
return _postcodeRepo.ValidatePostcode(model.Postcode, model.Suburb, model.State);
}
}
Преимущество этого подхода состоит в том, что он сохраняет ваши модели красивыми и чистыми и позволяет проверять сложную логику.
Если переключение на FluentValidator не является для вас вариантом, я бы предложил добавить в вашу модель дополнительное свойство под названием TaxRate и установить его до вызова метода Validate.
Это не идеально, но это означает, что вы не берете зависимость в хранилище в вашей модели.