In the last post we showed an api for how we can inject additional metadata into our validation results. The implementation is relatively straightforward - but there are a few moving parts that need to mesh together appropriately.
To preserve the transient nature of success and aggregate results, we only want to support metadata for warning and error; we therefore introduce an intermediate class to avoid repetition:
All this does is to declare the property Metadata and ensure it’s properly populated by the constructor.
We then modify ErrorResult to descend from ValidationResultWithMetadata:
The constructor accepts the metadata as you’d expect. The changes to WarningResult are similar.
Next, we modify our factory methods to make it easy to pass metadata when the consumer wants to do so:
Using the params keyword for these methods gives our consumers a choice about passing metadata, or not. It’s also a signature change we can make to the methods that doesn’t break any existing code. Once you’ve got a thousand references to .ErrorWhen() across your codebase, you really don’t want to have to manualy modify all of them for a change.
Again, I’ll elide the changes for warnings as they’re not substantively different.
All we need now for this to work is the ValidationMetadata class itself - and it’s just not that interesting, as it’s just a simple immutable container type:
There’s nothing in this tiny type that we haven’t already covered multiple times in this blog.
Next time we’ll work on eliminating our magic strings and making the API even easier to use.
Comments
blog comments powered by Disqus