Convenzione sulla configurazione - è uno scenario appropriato?

Question

Ho alcune classi di risultati che rappresentano i risultati piatti in una moda orientata agli oggetti.Il risultato piatto è come un flusso di testo e un formattatore forma forma i risultati piatti nelle proprietà del risultato.

Presumo che la mia convenzione sia costantemente <ResultName>formatter.È un buon caso per la convenzione sulla configurazione, e in tal caso, quale sarebbe simile a un prisma (se il prisma è importante a questa domanda).

Grazie.

Answer 1

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.

Answer 2

Nope this looks more like consistent naming to me. This is important too to have a "discoverable API", where you can find things easily.

Convention over configuration is where parts of your application hook up/work as expected if they follow a specific convention. e.g. Rails expects your Model, View and Controller to be in specific folder and with specific names. As long as you follow this convention, the framework auto-magically finds and wires them together. That doesn't mean that you "must" follow it always. There is also an option to override the default behavior but that would require you to add some stuff to some configuration/mapping file / write some code somewhere.

Convention over configuration helps to keep the 80% scenario simple and quick.