java 加载设置 - 最佳实践

Loading Settings - Best Practices

提问by

I'm at the point in my first real application where I am adding in the user settings. I'm using Java and being very OO (and trying to keep it that way) so here are my ideas:

我正在我的第一个真正的应用程序中添加用户设置。我正在使用 Java 并且非常面向对象（并试图保持这种状态）所以这是我的想法：

1. Load everything in the main()and pass it all 'down the line' to the required objects (array)
2. Same as above, but just pass the object that contains the data down the line
3. Load each individual setting as needed within the various classes.

1. 加载中的所有内容main()并将其全部“沿线”传递给所需的对象（数组）
2. 与上面相同，但只是将包含数据的对象向下传递
3. 根据需要在各种类中加载每个单独的设置。

I understand some of the basic pros and cons to each method (i.e. time vs. size) but I'm looking for some outside input as to what practices they've successfully used in the past.

我了解每种方法的一些基本优点和缺点（即时间与大小），但我正在寻找一些关于他们过去成功使用的实践的外部输入。

采纳答案by Isaac

Since configuration / settings are typically loaded once (at startup; or maybe a few times during the program's runtime. In any way, we're not talking about a very frequent / time-consuming process), I would prefer simplicity over efficiency.

由于配置/设置通常加载一次（在启动时；或者在程序运行时加载几次。无论如何，我们不是在谈论一个非常频繁/耗时的过程），我更喜欢简单而不是效率。

That rules out option number (3). Configuration-loading will be scattered all over the place.

这排除了选项编号 (3)。配置加载会散落在各处。

I'm not entirely sure what the difference is between (1) and (2) in your list. Does (1) mean "passing discreet parameters" and (2) mean "passing an object containing the entire configuration"? If so, I'd prefer (2) over (1).

我不完全确定您列表中的 (1) 和 (2) 之间有什么区别。(1) 是否意味着“传递谨慎的参数”和 (2) 是否意味着“传递包含整个配置的对象”？如果是这样，我更喜欢（2）而不是（1）。

The rule of thumb here is that you should keep things simple and concentrated. The advantage of reading configuration in one place is that it gives you better control in case the source of the configuration changes at some point.

这里的经验法则是，你应该让事情变得简单和集中。在一个地方读取配置的优点是它可以让您更好地控制配置源在某个时间点发生变化的情况。

回答by andersoj

Someone should stand up for the purported Java standard, the Preferences API... and it's most recent incarnation in JDK6. Edited to add, since the author seems to savvy XML, this is more appropriate than before. Thought I believe you can work XML juju with Propertiestoo, should the spirit take you.

有人应该站出来支持所谓的 Java 标准，即Preferences API……它是JDK6 中的最新版本。 编辑补充，由于作者似乎精通XML，所以比以前更合适。我想我相信你也可以用 XML juju 工作Properties，如果精神带你。

Related on SO: Preferences API vs. Apache solution, Is a master preferences class a good idea?

与 SO 相关：首选项 API 与 Apache 解决方案，主首选项类是个好主意吗？

(well, that's about all the standing up I'm willing to do.)

（好吧，这就是我愿意做的所有站立。）

回答by mtreit

Use a SettingsManager class or something similar that is used to abstract getting all settings data. At each point in the code where you need a setting you query the SettingsManager class - something like:

使用 SettingsManager 类或用于抽象获取所有设置数据的类似内容。在代码中需要设置的每个点上，您都可以查询 SettingsManager 类 - 例如：

int timeout = SettingsManager.GetSetting("TimeoutSetting");

You then delegate all of the logic for how settings are fetched to this single manager class, whose implementation you can change / optimize as needed. For instance, you could implement the SettingsManager to fetch settings from a config file, or a database, or some other data store, periodically refresh the settings, handle caching of settings that are expensive to retrieve, etc. The code using the settings remains blissfully unaware of all of these implementaton decisions.

然后，您将有关如何获取设置的所有逻辑委托给这个单一管理器类，您可以根据需要更改/优化其实现。例如，您可以实现 SettingsManager 以从配置文件、数据库或其他一些数据存储中获取设置，定期刷新设置，处理检索成本高的设置的缓存等。使用这些设置的代码仍然很幸福不知道所有这些实施决策。

For maximum flexibility you can use an interface instead of an actual class, and have different setting managers implement the interface: you can swap them in and out as needed at some central point without having to change the underlying code at all.

为了获得最大的灵活性，您可以使用接口而不是实际的类，并让不同的设置管理器实现该接口：您可以根据需要在某个中心点交换它们，而根本不必更改底层代码。

In .NET there is a fairly rich set of existing configuration classes (in the System.Configuration) namespace that provide this sort of thing, and it works out quite well.

在 .NET 中，有一组相当丰富的现有配置类（在 System.Configuration 中）命名空间提供此类功能，并且效果很好。

I'm not sure of the Java equivalent, but it's a good pattern.

我不确定 Java 的等价物，但它是一个很好的模式。

回答by Joseph Weissman

Here is a tutorial on the Properties class. From the Javadocs (Properties):

这是关于 Properties 类的教程。来自 Javadocs（属性）：

The Properties class represents a persistent set of properties. The Properties can be saved to a stream or loaded from a stream. Each key and its corresponding value in the property list is a string.

A property list can contain another property list as its "defaults"; this second property list is searched if the property key is not found in the original property list.

Properties 类表示一组持久的属性。属性可以保存到流或从流加载。属性列表中的每个键及其对应的值都是一个字符串。

一个属性列表可以包含另一个属性列表作为它的“默认值”；如果在原始属性列表中找不到属性键，则搜索第二个属性列表。

The tutorial gives the following example instantiation for a typical usage:

本教程给出了以下典型用法的示例实例化：

    . . .
// create and load default properties
Properties defaultProps = new Properties();
FileInputStream in = new FileInputStream("defaultProperties");
defaultProps.load(in);
in.close();

// create application properties with default
Properties applicationProps = new Properties(defaultProps);

// now load properties from last invocation
in = new FileInputStream("appProperties");
applicationProps.load(in);
in.close();
. . .

You could, of course, also roll your own system fairly directly using a file-based store and an XML or YAML parser. Good luck!

当然，您也可以使用基于文件的存储和 XML 或 YAML 解析器相当直接地推出您自己的系统。祝你好运！

回答by Thorbj?rn Ravn Andersen

We have recently started using JSR-330 dependency injection (using Guice from SVN) and found that it was possible to read in a Properties file (or any other map) and bind it inside Guice in the module in the startup code so that the

我们最近开始使用 JSR-330 依赖注入（使用来自 SVN 的 Guice），发现可以读取 Properties 文件（或任何其他映射）并将其绑定到启动代码中模块中的 Guice 中，以便

@Inject @Named("key") String value

string was injected with the value corresponding to the key when that particular code was called. This is the most elegant way I have ever seen for solving this problem!

当调用特定代码时，字符串被注入与键对应的值。这是我见过的最优雅的解决这个问题的方法！

You do not have to haul configuration objects around your code or sprinkle all kinds of magic method calls in each and every corner of the code to get the values - you just mention to Guice you need it, and it is there.

您不必在代码周围拖曳配置对象或在代码的每个角落撒上各种魔法方法调用来获取值 - 您只需向 Guice 提及您需要它，它就在那里。

Note: I've had a look at Guice, Weld (Seam-based) and Spring which all provide injection, because we want JSR-330 in our own code, and I like Guice the best currently. I think the reason is because Guice is the clearest in its bindings as opposed to the under-the-hood magic happening with Weld.

注意：我看过 Guice、Weld（基于 Seam）和 Spring，它们都提供注入，因为我们希望在我们自己的代码中使用 JSR-330，而且我目前最喜欢 Guice。我认为原因是 Guice 的绑定最清晰，而不是 Weld 的幕后魔法。