如果我的程序的“服务”负责得到自己的配置？ [英] Should my program's "services" be responsible to get their own configuration?

问题描述

我的计划由多个服务组成（我不是在说 SOA ，所以不要困惑），并且这些服务中的每一个都使用一些配置（例如，目录路径）。这个配置应该从配置文件中读取，因为它们会改变（不改变程序的逻辑）。

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

这个问题实际上非常类似于这个问题，只有我的更具体的关于这些：

• 我的程序的服务不是通用的，不应该被另一个重用。他们已经使用通用工具，它们的功能是简单地连接这些工具。


• 这些服务的目标是清晰和直接的，有时需要多个动作。这意味着我的服务不需要只负责一个操作（虽然你可以在逻辑和准备例如配置之间分开）。

感谢。

解决方案

我会倡导这些方法的组合，只要你设法实现它在一个优雅（我已经看到这样做在优雅和可怕的实现）：

• 有一个数据结构的配置可以实现设置子集
  （在Perl中，它是非常简单的超重哈希，在其他语言中它有点更加冗长，但重叠的地图在彼此的顶部）。为了更精确，您的数据结构将为

  
  
  
  
  

  • 全局Singleton配置映射

    
    

  • 作为参数传递本地配置映射

  
  



• 配置加载程序类，可以：

  
  
  
  
  

  • 以作为参数传递本地配置映射

    
    

  • 使用组件所需的一组键

  
  

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

    / li>
    

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

  
  

<这样，服务的每个调用者都有完全自由的生活在一个无忧的词，让每个服务照顾自己的配置需要，或为了更可控的行为，有一个选项传递

$ b $

b

这有很大的测试优势，因为测试框架可以通过每个测试所需的特定配置局部覆盖。

My program consists from several "services" (I'm not talking about SOA, so don't get confused), and each of these "services" is using some configuration (for example, a directory path). This configuration should be read from a configuration file, as they tend to change (without changing the program's logic, that is).

So my question is this - Should each "service" receive its configuration when invoked, or should it be responsible for getting its own configuration?

This question is actually very similar to this question, only mine is more specific about these:

• My program's "services" aren't generic, and aren't supposed to be re-used by another. They already use generic tools, and their functionality is to simply connect between those tools. This means that it is not immediately obvious for them to receive their configuration, as their target is very clear and direct.
• The target of these "services", being clear and direct, sometimes requires more than one action. This means that my "services" aren't necessary responsible for only one action (although you might separate between logic and preparations such as configuration).

Thanks.

解决方案

I would advocate a combination of these approaches, as long as you manage to implement it in an elegant way (I have seen this done in both elegant and horrendous implementations):

• Have a data structure for configuration that can implement settings sub-sets (in Perl it is extremely simple with super-imposed hashes, in other languages it's a bit more wordy but overlaying maps on top of each other works as well). To try to be more precise, your data structures will be

  • A global Singleton Configuraton map

  • A "passed as parameter" local configuration map

• Have a Configuration loader class, which can:

  • Take "passed as parameter" local configuration map

  • Take a set of keys needed by the component

  • Superimpose the local map onto global configuration map

  • Allow the components to query out the values from combined map.

• This way, each caller of the services has a complete freedom to either live in a worry-free word and let each service take care of its own configuration needs, or for a more controllable behavior, has an option of passing specific configuration settings it wants to control to the service (either creating the settings values by hand, or cloning data subset from global configuration and adjusting it).

This has major testing benefit, since the test framework can pass specific configuration local overrides needed for each test.

这篇关于如果我的程序的“服务”负责得到自己的配置？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！