I have some Result classes that represent flat results in an object oriented fashion. The flat result comes in as a text stream, and a Formatter formats the flat results into the properties of the Result.
I assume my convention will consistently be <ResultName>Formatter. Is this a good case for Convention Over Configuration, and if so, what would that look like in Prism (if Prism matters to this question).
Thanks.
I'm not sure where Prism fits into this, unless the Result-Formatter pair are something Prism-specific.
Beyond that, I think this is a fine case for convention-over-configuration, because you could create any number of result types and formatters without having to add them to any mapping or configuration classes/files.
As the creator of this convention and API, however, the onus falls to you to implement and support the convention. Assuming that you will reflectively discover formatters capable of handling results, will this be done upon first request or application start? How will you cache the mappings?
A big part of convention-over-configuration is taking decision-making off the shoulders of the end developer in favour of reasonable defaults and a standard to which they can adhere, but that means that the decisions fall to you and the level of override granularity that you provide must be determined. For example, can a consumer of this API have formatters defined in more than one assembly (this might be a Prism-relevant consideration)? If so, how are those assemblies specified? Can a consumer deviate from the convention and map differently-named formatters to result types?
It sounds like this is an API that only you will consume, so much of this is moot, but these are just some considerations that would apply generally.