如何组织代码，以便我们可以移动和更新它，而无需编辑配置文件的位置？ [英] How to organize code so that we can move and update it without having to edit the location of the configuration file?

问题描述

我考虑的问题是如何编写代码，可以轻松知道所需的配置文件的位置，而且是可移植的，无需任何编辑，从一个环境到另一个。我们不想编辑配置文件的位置以使代码适应每个新环境，例如每次我们将代码从开发环境移动到生产环境。该方法不应依赖于不可用的资源，例如对用户定义的环境变量的访问或对特定目录的访问。例如，似乎使用DOCUMENT_ROOT作为配置文件的基本位置是要走的路，但这不是通用的。首先，在命令行环境中，DOCUMENT_ROOT没有意义。第二，可以给程序员仅访问DOCUMENT_ROOT的子文件夹。另一个要求是配置文件可以依赖于运行时已知的值，例如调用应用程序的用户，如此问题如何根据用户选择从未知位置加载配置文件。位置。

The issue that I consider is how to write code that can easily know the location of a required config file and yet is portable, without any edit, from an environment to another. We don't want to edit the location of the configuration file to adapt the code to each new environment, say each time we move the code from a development environment to production. The method should not rely on resources that are not universally available, such as an access to user-defined environment variables or an access to a specific directory. For example, it may seem that using the DOCUMENT_ROOT as a base location for the config file is the way to go, but that is not universal. First, in a command line environment the DOCUMENT_ROOT makes no sense. Second, a programmer might be given access to a sub-folder of the DOCUMENT_ROOT only. Another requirement is that the configuration file could depend on values known at run time, say the user who call the application, as in this question How to load a config file based on user selection from "unknown" location .

问题不是配置文件在特定环境中的最佳位置，例如将用户配置文件放在窗口中的位置。程序员仍然必须找出最佳位置，以便最终用户可以轻松找到配置文件。问题是如何这个位置，无论是什么，即使它取决于在运行时已知的值，可以以便携式方式传递给代码。

The question is not what is the best location of the configuration file in specific environments, such as Location to put user configuration files in windows . The programmers would still have to figure out the best location so that end users could easily find the configuration file. The question is how this location, whatever it is, even if it depends on values known at run time, can be passed to the code in a portable manner.

推荐答案

一种方法是设计任何脚本文件，记住它将包含在另一个文件中，获取到只定义配置文件的目录的包装器脚本，以受益于所包括的文件和其中包括的文件。一旦此目录路径已知，可以从其中的命名配置文件获取其他配置值。这是因为在从存储库或测试环境更新代码时，包装器脚本不会更新。这种方法似乎普遍适用：不需要任何类型的特殊支持，例如访问用户定义的环境变量或服务器中的某个特定目录。只要你有访问的代码，这是一个严格的最低要求，它的工作原理。此外，脚本通常被自然地设计为包含在另一个文件中 - 因此是自然的。

One approach is to design any script file with in mind that it is to be included in another file and so on until we get to a wrapper script that only defines the directory of the config file to the benefit of the included file and other included files therein. Once this directory path is known, other configuration values can be obtained from a named configuration file within it. This works because the wrapper scripts are not updated when we update the code from a repository or testing environment. This approach seems universally applicable : no special support of any kind such as an access to user defined environment variables or to some specific directory in the server is needed. As long as you have access to the code, which is a strict minimum to expect, it works. Also, scripts are often naturally designed to be included in another file - so it is natural.

这种方法只需要我们约定常量的名称，例如CONFIG_DIRECTORY。如果每个程序员都同意在配置文件的这个常量指定的位置搜索，那么代码的任何用户都可以把配置文件放在任何地方，并相应地定义这个常量。

The approach only requires that we agree on a convention for the name of the constant, say CONFIG_DIRECTORY. If every programmer would agree to search at the location specified by this constant for the config file, then any user of the code could put the config file anywhere and just define this constant accordingly.

在Linux中，他们有配置文件夹/ etc。因此，在非常大的背景下，普遍认同的标准的概念已经存在。这是与这里建议的相同的想法，除了它是相同的常数为所有机器，有人可能无法访问该级别的服务器。此外，我们失去了为不同的包装脚本使用不同的配置目录的可能性。允许通用标准为常数名称，例如CONFIG_DIRECTORY，而不是固定常量'/ etc'，似乎只是一个额外的灵活性，没有额外的不便。它需要我们在一些包装器脚本中定义这个常量，但如果没有定义，我们可以回到旧的方法。如果严格应用该方法，结果将是服务器文档根中所需的所有脚本将只是定义配置目录的简单包装器。这似乎很酷。通常人们说，在文档根之外有重要的代码是更安全的。

In Linux, they have the folder /etc for config files. So, the notion of an universally agreed standard in a very large context is already there. This is the same idea than the one proposed here, except that it is the same constant for all machines and someone might not have access to that level of the server. Moreover, we lose the possibility to have different configuration directories for different wrapper scripts. Allowing the universal standard to be a constant name, say 'CONFIG_DIRECTORY', instead of being the fixed constant '/etc', seems just an extra flexibility with no additional inconvenient. It does require that we define this constant in some wrapper script, but we could fall back to the old approach if it is not defined. The outcome, if the approach is strictly applied, would be that all the scripts required in the server document root would only be simple wrappers that define a configuration directory. That seems cool. Often people say that it is safer to have important code outside the document root.

这篇关于如何组织代码，以便我们可以移动和更新它，而无需编辑配置文件的位置？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！