C# 约定优先于配置-这是一个合适的场景吗？

我有一些结果类，它们以面向对象的方式表示平面结果。平面结果以文本流的形式出现，格式化程序将平面结果格式化为结果的属性

我假设我的约定将始终是格式化程序。这是约定优先于配置的好例子吗？如果是，在Prism中会是什么样子（如果Prism对这个问题很重要的话）

---

谢谢。

我不确定Prism适合这个应用，除非结果格式化程序对是Prism特有的

除此之外，我认为这是约定优于配置的好例子，因为您可以创建任意数量的结果类型和格式化程序，而无需将它们添加到任何映射或配置类/文件中

但是，作为该约定和API的创建者，您有责任实现和支持该约定。假设您将以反射方式发现能够处理结果的格式化程序，那么这将在第一次请求或应用程序启动时完成吗？如何缓存映射

约定优先于配置的一大部分是让最终开发人员放弃决策权，支持合理的默认设置和他们可以遵守的标准，但这意味着决策权属于您，您提供的覆盖粒度级别必须确定。例如，此API的使用者是否可以在多个程序集中定义格式化程序（这可能是与Prism相关的考虑事项）？如果是，如何指定这些程序集？使用者能否偏离约定，将不同名称的格式化程序映射到结果类型

---

这听起来像是一个只有您才会使用的API，所以大部分内容都是没有意义的，但这些只是一些普遍适用的注意事项。

不，在我看来，这更像是一致的命名。这对于拥有一个“可发现的API”也很重要，在这个API中，您可以很容易地找到东西

约定优先于配置是指应用程序的某些部分按照特定约定进行连接/工作的情况。e、 g.Rails希望您的模型、视图和控制器位于特定的文件夹中，并具有特定的名称。只要遵循此约定，框架就会自动神奇地查找并将它们连接在一起。 这并不意味着你“必须”一直遵循它。还有一个选项可以覆盖默认行为，但这需要您向某些配置/映射文件添加一些内容，或者在某处编写一些代码

---

约定优先于配置有助于保持80%场景的简单和快速。

我认为OP所引用的一致命名是为了支持自动连接结果和格式化程序，正如您所描述的那样，只有在这里OP必须提供魔法来支持他正在建立的约定。