约定优于配置——这是一个合适的场景吗？
我有一些 Result 类，它们以面向对象的方式表示平面结果。平面结果以文本流形式出现，格式化程序将平面结果格式化为结果的属性。
我假设我的约定将始终是
谢谢。
I have some Result classes that represent flat results in an object oriented fashion. The flat result comes in as a text stream, and a Formatter formats the flat results into the properties of the Result.
I assume my convention will consistently be <ResultName>Formatter. Is this a good case for Convention Over Configuration, and if so, what would that look like in Prism (if Prism matters to this question).
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不确定 Prism 在哪里适合这个，除非结果格式化程序对是 Prism 特定的。
除此之外，我认为这是约定优于配置的一个很好的例子，因为您可以创建任意数量的结果类型和格式化程序，而无需将它们添加到任何映射或配置类/文件中。
然而，作为该约定和 API 的创建者，您有责任实施和支持该约定。假设您将反思地发现能够处理结果的格式化程序，这会在第一次请求或应用程序启动时完成吗？您将如何缓存映射？
约定优于配置的一个重要部分是将决策从最终开发人员的肩上移开，转而支持合理的默认值和他们可以遵守的标准，但这意味着决策取决于您和覆盖粒度级别必须确定您提供的内容。例如，该 API 的使用者是否可以在多个程序集中定义格式化程序（这可能是与 Prism 相关的考虑因素）？如果是这样，这些程序集是如何指定的？消费者是否可以偏离约定并将不同名称的格式化程序映射到结果类型？
听起来这是一个只有您才会使用的 API，所以其中大部分内容都没有实际意义，但这些只是一些普遍适用的注意事项。
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.
不，这对我来说看起来更像是一致的命名。这对于拥有“可发现的 API”也很重要，您可以在其中轻松找到东西。
约定优于配置是指应用程序的某些部分如果遵循特定约定，则按预期连接/工作。例如，Rails 期望您的模型、视图和控制器位于特定文件夹中并具有特定名称。只要您遵循此约定，框架就会神奇地自动找到它们并将它们连接在一起。
这并不意味着您“必须”始终遵循它。还有一个选项可以覆盖默认行为，但这需要您向某些配置/映射文件添加一些内容/在某处编写一些代码。
约定优于配置有助于保持 80% 的场景简单快捷。
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.