java - 在 Java 中存储应用程序的 conf 数据的正确方法是什么？

Question

您在哪里存储特定于用户和特定于机器的运行时间 J2SE 应用程序的配置数据？
(例如，Windows 上的 C:\Users\USERNAME\AppData\Roaming 和 Unix 上的/home/username)
您如何以独立于平台的方式在文件系统中获取这些位置？

Answer 1

先说格式:

Java property files适用于键/值对(也自动处理换行符)。通过使用“点符号”可以实现一定程度的结构化。缺点是该结构不允许您轻松枚举顶级配置实体并以向下钻取的方式工作。最适合用于一小组通常可调整的特定于环境的设置

XML 文件 - 经常用于各种 Java 框架(特别是 J2EE 和 Spring)的更复杂配置。我建议您至少了解 Spring - 即使您决定不使用它，它也包含许多值得了解的想法。如果您决定推出自己的 XML 配置，我建议您使用 XStream使用自定义序列化选项，或者如果您只需要解析一些 XML，请查看 XOM .顺便说一句，Spring 还允许您插入自定义 XML 配置语言，但它是 relatively complex task . XML 配置最适合用于最终用户无法看到或调整的更复杂的“内部”配置。

序列化 Java 对象 - 一种保持对象状态并稍后恢复的快速简便的方法。如果您编写配置 GUI 并且您不关心配置是否是人类可读的，则很有用。当心 compatibility issues当你进化类(class)时。

首选项 - 在 Java 1.4 中引入, 允许您在特定于平台的存储中存储键入的文本、数字、字节数组和其他原语。在 Windows 上，这是注册表(您可以在 HKLM 或 HKCU 下的/Software/JavaSoft/Prefs 之间进行选择)。在 Unix 下，相同的 API 在用户 home 或/etc 下创建文件。每个偏好配置单元都可以作为 XML 文件导出和导入。您可以指定 PreferencesFactory 的自定义实现接口(interface)通过将“java.util.prefs.PreferencesFactory”JVM 属性设置为您的实现类名称。

一般来说，根据您的应用场景，使用 prefs API 可能是好事也可能是坏事。

如果您计划在具有不同配置的同一台机器上运行相同代码的多个版本，那么使用 Preferences API 是一个坏主意。

如果您计划在受限环境(Windows 域或严格管理的 Unix 机器)中使用该应用程序，您需要确保您可以正确访问必要的注册表项/目录。这让我不止一次感到意外。

当心漫游配置文件(复制的家庭目录)，当涉及多台 Activity 机器时，它们弥补了一些有趣的场景。

首选项不像应用程序目录下的配置文件那么明显。大多数桌面支持人员不期望也不喜欢它们。

关于首选项的文件布局，它再次取决于您的应用程序。一个通用的建议是:

将大部分 XML 文件打包在应用程序的 JAR 中，位于根目录或/META-INF 目录下。这些文件将是只读的，并被视为应用程序的私有(private)文件。

将用户可修改的配置放在 $APP_HOME/conf 下。它应该主要由属性文件组成，偶尔还有一个简单的 XML 文件(XStream 序列化)。这些文件作为安装过程的一部分进行了调整，通常用户无法使用。

在 user-home 下，在一个点目录(即“~/.myapplication”)中存储任何用户配置。用户配置可能会覆盖应用程序 conf 目录中的配置。在应用程序内进行的任何更改都在此处(另请参见下一点)。

您还可以使用 $APP_HOME/var 目录来存储特定于该应用程序实例(而不是用户)的任何其他可变数据。这种方法的另一个优点是您可以通过简单复制一个目录来移动和备份整个应用程序及其配置。

这说明了一些用于管理配置的标准技术。您可以使用不同的库和工具来实现它们，从原始 JRE 开始，添加 Spring/Guice 或使用完整的 J2EE 容器(可能带有嵌入式 Spring)

其他管理配置的方法是:

使用 multiple base directories用于使用不同配置运行应用程序的多个实例。

使用 lightweight registries用于集中配置管理

一个集中管理的配置管理数据库 (CMDB) 文件，包含每台机器的主机特定值，每晚都会同步到所有生产主机。应用程序使用模板化配置，并在运行时根据当前主机名从 CMDB 中进行选择。