约定配置 - 这是一个适当的场景吗？

Question

我有一些Result类以面向对象的方式表示平面结果。平面结果作为文本流出现，Formatter将平面结果格式化为Result的属性。

我认为我的约定将始终是<ResultName>格式化程序。这对于Over Over Configuration来说是一个很好的例子，如果是这样的话，那么Prism会是什么样子（如果Prism对这个问题很重要）。

感谢。

Answer 1

我不确定Prism在哪里适合这个，除非Result-Formatter对是Prism特有的。

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

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

配置约定的很大一部分是让决策者脱离最终开发人员的肩膀，支持合理的默认值和他们可以遵守的标准，但这意味着决策落在你和层面上必须确定您提供的覆盖粒度。例如，此API的使用者是否可以在多个程序集中定义格式化程序（这可能是与Prism相关的考虑因素）？如果是这样，那些组件是如何指定的？消费者是否可以偏离约定并将不同命名的格式化程序映射到结果类型？

听起来这是一个只有你会消耗的API，所以这很多都没有实际意义，但这些只是一些适用的考虑因素。

Answer 2

不，这看起来更像是对我的一致命名。这对于拥有“可发现的API”非常重要，您可以轻松找到它。

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

约定优于配置有助于保持80％的场景简单快捷。