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

Question

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

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

谢谢。

Answer 1

我不确定棱镜如何适应这种情况，除非Result-Formatter对是棱镜特定的。

除此之外，我认为这对于convention-over-configuration来说是一个很好的例子，因为你可以创建任意数量的结果类型和格式化程序，而不必将它们添加到任何映射或配置类/文件中。

但是，作为这个约定和API的创建者，责任落在你的实施和支持公约之上。假设您将反思性地发现能够处理结果的格式化程序，这是否会在首次请求或应用程序启动时完成？你将如何缓存映射？

约定优先配置的一大部分是将决策权交给最终开发者，以支持合理的默认值和他们可以遵守的标准，但这意味着决策权属于您和必须确定您提供的覆盖粒度级别。例如，该API的使用者是否可以在多个程序集中定义格式化程序（这可能是与Prism有关的考虑因素）？如果是这样，那些组件是如何指定的？消费者能否偏离约定并将不同名称的格式符映射为结果类型？

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

Answer 2

不，这看起来更像是一致的命名给我。这对于拥有“可发现的API”也很重要，您可以在其中轻松查找。

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

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