What is the replacement for Custom/CustomAsync?

I have a lot of code like this:

CustomAsync(o => {
   // do some logic using multiple fields
   return new ValidationFailure("PropertyThatIsNotInTheModel", "custom error message");
}

I just updated to the latest version and it tells me to use RuleFor, but I’m not sure how:

Rulefor(o => o).MustAsync(o => {
    // return new ValidationFailure won't work here
});

So. what exactly is the replacement for the previous code?

[JeremySkinner]

@nvivo it saddens me that you think I “don’t care”…I’ve taken the time to engage with you and to try and explain the rationale here…I’m sorry if I didn’t do a very good job of that, but just because we disagree on something doesn’t mean I don’t care, and suggesting that really is quite rude considering how much time I spend on this project and answering questions (for free). Instead of complaining, it would be great if you could work with me here to come up with something that works for you, while still fitting with the direction I want to take the project.

So that being said:

@nvivo @grovesNL, would you have a preference for an alternative api that allows you to return multiple validation failures (like Custom/CustomAsync does), but in a way that fits better with the fluent api? The existing Custom/CustomAsync really doesn’t with the style of the rest of the project, so the aim here would be to have something that works similarly to other validators in terms of method chaining, but gives you complete control over the creation of the ValidationFailures.

An initial thought would be something like this:

RuleFor(x=>x).Custom(context => {
  return new[]  {
     new ValidationFailure("SomeProperty", "message");
  };
});

This could then exist in a rule chain alongside other validators (and could also be used on non model-level rules). I don’t particularly like returning an array here, so an alternative would have some useful helper methods on the context object to clean this up:

RuleFor(x=>x).Custom(context => {
   context.AddFailure("SomeProperty", "message");
});

Of course you could do multiple conditional failures:

RuleFor(x=>x).Custom(context => {
   context.AddFailure("SomeProperty", "message");
   if(context.Instance.SomeConditionIsMet) {
     context.AddFailure("SomeProperty", "message");
   }
});

I could also envisage AddFailure being clever enough to infer the property name. For example, if using this against a property rather than a model-level rule you could call AddFailure(“message”) and it would infer the current property unless you choose to override it.

One downside is I don’t think it’d be very clear how something like WithMessage would act on this. e.g. If you call RuleFor.Custom(…).WithMessage(“Foo”) what should this do? It could just be a no-op, or possibly throw a NotSupportedException.

Thoughts/suggestions?

[JeremySkinner]

Just a FYI for anyone who comes across this thread - it is now possible to call AddFailure(“message”) without a property name for model-level rules.