【发布时间】：2011-05-18 14:54:41
【问题描述】：
我有一些 Result 类以面向对象的方式表示平面结果。平面结果以文本流的形式出现，Formatter 将平面结果格式化为 Result 的属性。
我假设我的约定将始终是<ResultName>Formatter。这是约定优于配置的好案例吗？如果是，那么在 Prism 中会是什么样子（如果 Prism 对这个问题很重要）。
谢谢。
【问题讨论】：
标签： c# convention-over-configur
【发布时间】：2011-05-18 14:54:41
【问题描述】：
我不确定 Prism 的适用范围，除非 Result-Formatter 对是 Prism 特有的。
除此之外，我认为这是约定优于配置的一个很好的案例，因为您可以创建任意数量的结果类型和格式化程序，而无需将它们添加到任何映射或配置类/文件中。
但是，作为此约定和 API 的创建者，您有责任实施和支持该约定。假设您将反思地发现能够处理结果的格式化程序，这会在第一次请求或应用程序启动时完成吗？您将如何缓存映射？
约定优于配置的很大一部分是将决策从最终开发人员的肩上移开，以支持合理的默认设置和他们可以遵守的标准，但这意味着决定权落在您和级别必须确定您提供的覆盖粒度。例如，该 API 的使用者是否可以在多个程序集中定义格式化程序（这可能与 Prism 相关）？如果是这样，这些程序集是如何指定的？消费者可以偏离约定并将不同命名的格式化程序映射到结果类型吗？
听起来这是一个只有您会使用的 API，其中大部分内容都没有实际意义，但这些只是一些普遍适用的考虑因素。
【讨论】：
不，这对我来说更像是一致的命名。拥有一个“可发现的 API”也很重要，您可以在其中轻松找到内容。
约定优于配置是指应用程序的某些部分在遵循特定约定的情况下按预期连接/工作。例如Rails 期望您的模型、视图和控制器位于特定文件夹中并具有特定名称。只要您遵循此约定，框架就会自动找到它们并将它们连接在一起。 这并不意味着您“必须”始终遵循它。还有一个选项可以覆盖默认行为，但这需要您在某些配置/映射文件中添加一些内容/在某处编写一些代码。
约定优于配置有助于保持 80% 的场景简单快捷。
【讨论】：
-
我认为 OP 所指的一致命名是为了支持自动连接结果和格式化程序，就像你描述的那样，只有在这里 OP 必须提供支持他的约定的魔力正在建立。