我的程序的“服务”是否应该负责获得自己的配置？

Question

我的程序包含几个“服务”（我不是在谈论SOA，所以不要混淆），并且每个“服务”都在使用某些配置（例如，目录路径） ）。应该从配置文件中读取此配置，因为它们往往会更改（不改变程序的逻辑）。

所以我的问题是 - 每个“服务”在调用时是否应该接收其配置，还是应该负责获取自己的配置？

这个问题实际上与this问题非常相似，只有我的问题更具体：

• 我的程序的“服务”不是通用的，不应该被其他人重用。他们已经使用了通用工具，他们的功能就是简单地连接这些工具。这意味着他们接收配置并不是很明显，因为他们的目标非常明确和直接。
• 这些“服务”的目标，明确而直接，有时需要不止一个动作。这意味着我的“服务”不仅仅需要对一个操作负责（尽管您可以将逻辑和准备工作分开，例如配置）。

感谢。

Answer 1

我会提倡这些方法的组合，只要你设法以优雅的方式实现它（我已经在优雅和可怕的实现中看到了这一点）：

• 拥有可以实现设置子集的配置数据结构 （在Perl中，使用超级强加的哈希非常简单，在其他语言中它更加冗长，但叠加在彼此之上的地图也适用）。为了更加精确，您的数据结构将是

  • 全局Singleton Configuraton地图

  • “作为参数传递”本地配置图

• 有一个Configuration loader类，可以：

  • 将“传递为参数”本地配置图

  • 获取组件所需的一组键

  • 将本地地图叠加到全球配置地图

  • 允许组件查询组合地图中的值。

• 这样，服务的每个调用者都可以完全自由地生活在一个无忧无虑的单词中，让每个服务都能满足自己的配置需求，或者为了更可控的行为，可以选择将要控制的特定配置设置传递给服务（手动创建设置值，或从全局配置中克隆数据子集并进行调整）。

这具有主要的测试优势，因为测试框架可以传递每个测试所需的特定配置本地覆盖。

Answer 2

听起来你的应用程序更像是一种服务而不是一种工具（期望加载不同的配置选项），所以除了最简单的配置选项之外，我会说是的。

随着您的服务变得越来越复杂，毫无疑问会有很多配置选项，比如数据库连接字符串，外部服务URL，缓存提供程序等，smtp主机等。过了一段时间，您只能进行测试如果预先设置了多个配置选项，您可以将其保存在配置文件中并随应用程序一起分发。

对于需要动态配置的服务，我通常会向服务发送“刷新配置”消息，实质上是告诉它使用新配置安全地重新加载。