管理配置数据的最佳方法是什么
我正在开发一个包含 4 个产品的产品套件。目前,所有配置数据都在 XML 或属性文件中。这种方法不可维护,因为我们必须为不同的环境(例如生产、开发等)管理不同的配置文件。
那么,处理配置数据的最佳方式是什么?
另外,我们可以将其模块化为一个单独的模块吗?这样所有的产品都可以使用这个模块。 我们不想使用属性文件。我正在寻找一种解决方案,在该解决方案中,我们可以将所有配置特定代码移动为新的配置模块,并将所有配置数据保留在数据库中。
I am working on a product suite which has 4 products. Right now, all of the configuration data is either in the XML or properties files.This approach is not maintainable as we have to manage different configuration file for different environment(for e.g. Production, Development etc).
So, what is the best way to handle configuration data?
Also, can we modularize this into a separate module? So that all products can use this module.
We don't want to use the property files. I am looking for a solution in which we can move all of the configuration specific code as a new configuration module and persist all the configuration data in database.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
使用 commons-configuration,您可以使用统一的 API 来访问属性,无论如何 它们被表示为 - .properties、xml、JNDI 等。例如:
config.properties
:config.xml
:在这两种情况下,它们都可以通过类似的方式访问:
Using commons-configuration you have a unified API for accessing the properties, no matter how they are represented - .properties, xml, JNDI, etc. For example:
config.properties
:config.xml
:in both cases they will be accessible with something like:
你就快到了...我将保持相同的方法,并为通过类似于以下任一方法运行的应用程序实例引入正确的配置文件:
以不同的方式命名所有配置文件并让您的应用程序通过一些独特的标准(用户名、主机名等)将它们拉入:
将它们保留在代码库之外的基于应用程序假设存在的环境变量的位置:
我已经甚至在同一个项目中使用这些方法的组合(#1 用于构建过程配置,#2 用于运行时配置)。
You're almost there... I would keep your same approach and pull in the correct configuration file for the instance of the application that is running by a method similar to either of the following:
Name all of your configuration files differently and have your application pull them in by some unique criteria (username, hostname, etc.):
Keep them outside the codebase in a location based on an environment variable that the application assumes exists:
I've even used a combination of these approaches on the same project (#1 for build process configurations and #2 for runtime configurations).
如果您的应用程序使用数据库,您可以创建一个“配置”表,如下所示:
可以使用 init 脚本(例如 init.sql)初始化它,其内容如下:
这种方法的好处如下:
您的代码
每用户或每组设置
添加用户/组 ID,
运行时如果您需要这样做,
DAO、Cayenne...)您通常用来
处理核心应用程序数据
处理配置数据
If your applications work with a database, you can create a "configuration" table as follows:
You would initialize it using an init script, say init.sql with contents along the lines of:
The benefits of this approach are as follows:
your code
per-user or per-group settings by
adding a user/group id
runtime if you need to do so
DAO, Cayenne...) you normally use to
handle core application data to
handle configuration data
对于我们所有的环境,配置数据以属性文件的形式存在于目标计算机上。我们使用 PropertyPlaceholderconfigurer< /a> 从 SpringFramework 将这些属性绑定到我们的应用程序,以保持跨环境的可移植性。
例如,只要我知道 /etc/myapp/database.properties 将出现在我的应用程序将运行的任何机器上,那么在我的 spring 配置中,我只需要类似这样的东西:
有很多选项关于属性文件可以存放在哪里的 Spring 类。您甚至可以进行替换并将它们作为环境变量传递:
在 bash_profile (或其他)中:
export JAVA_OPTS="-Ddatabase.configuration.file.url=file:///etc/myapp/database.properties"
或者只是在调用“java”时传入相同的 -D 选项,具体取决于您在做什么。
FWIW,我们将属性文件单独维护为 RPM。
For all of our environments, configuration data lives on the target machines in the form of properties files. We use PropertyPlaceholderconfigurer from SpringFramework to bind these properties to our apps to keep things portable accross environments.
For example, as long as I know that /etc/myapp/database.properties will be present on whatever machine my app will be running on, then in my spring configuration, I just need something like so:
There are a bunch of options for that Spring class about where properties files can live. You can even make them substitutions and pass them in as environment variables:
And in bash_profile (or whatever):
export JAVA_OPTS="-Ddatabase.configuration.file.url=file:///etc/myapp/database.properties"
Or just the same -D option passed in when you call "java" depending on what you are doing.
FWIW, we maintain our properties files separately as RPMs.
有很多不同的策略。所有这些都很好,取决于最适合您的。
There are plenty of different strategies. All of them are good and depends on what suit you best.
环境变量是最简单的方法。像其他任何时候一样设置它们,使用
System.getenv("...")
访问它们Environment variables are just about the easiest way to go. Set them as you would any other time, access them w/
System.getenv("...")
2023 年的现代解决方案:
最好的选择是创建 Spring Boot Java 应用程序,并在
application.properties
或application.yml< 中定义所有属性。 /代码> 文件。
优点:
Modern solution in 2023:
Your very best bet is to create Spring Boot Java application and define absolutely all of your properties in the
application.properties
orapplication.yml
file.Pros: