As alluded in the prior post, all of our return types so far have been
ValidationResult - but our consumers will need to know whether they have a success or an error in order to make decisions.
We don’t want them to have to explicitly cast values - that would be boilerplate they’d need to write every time … and elimination of boilerplate is one of our primary motivations.
What we’ll do is to add a couple of public members to
ValidationResult to take care of the conversions:
HasErrors allows our consumers to test if we have any errors at all, while
Errors() allows them to iterate across those errors when they want all the gory details:
The implementation for
SuccessResult is straightforward - there’s no error to report:
The static member
_emptyErrors is a little tweak that allows us to return an empty list of errors without having to create a new one each time.
ErrorResult is a little more complex - but only just …
AggregateResult, the results aren’t hard coded; instead, they have to be based on the messages contained in the
I’m somewhat torn by these implementations of
Errors() - while they are clean and clear, they do result in the enumerable being recreated every time the collection is enumerated. One alternative would be to create internal lists, to return the same instance every time. However, I’m not convinced that the saving is worth the memory cost.
Next time we’ll return to the construction of
AggregateResult and how we’ll handle that.