使用spring配置应用程序属性

Question

由于我已经有application.properties，其中定义了数据库连接设置，我决定将我的应用程序特定设置也放入该文件中是好的。更进一步 - 当 spring 读取这些属性时，我将我的 Settings bean 声明如下

<bean name="settingsBean" class="com.tickets.constants.Settings">
    <property name="settings">
        <props>
            <prop key="backup.dir">${backup.dir}</prop>
            <prop key="smtp.host">${smtp.host}</prop>
        </props>
    <property>
 </bean>

现在，有时会发生，我需要类中的一些属性，这些属性并不直接在 spring 上下文中。是的 - 我可以从我的 web 应用程序上下文中获取 spring 上下文，或者将设置作为方法参数传递给实用程序类，但这是我的替代方法（这是 Settings 类）：

private static Properties staticSettings;

@PostConstruct
public void init() {
    // making the settings available for static access
    staticSettings = settings;
}

现在，这看起来有点不对劲。但我想不出不使用它的充分理由。 所以要提出这个问题 - 有什么理由不使用我的方法，还有更好的方法吗？

Answer 1

你是对的，你的解决方案“感觉”错了 - 静态和实例的交互看起来像是一种反模式，但它有点难以掌握。

我的直觉是在不牺牲 Spring 集成的情况下进一步推动静态，并使类本身更加内部一致：

public class Settings {

    private static Settings instance;

    public static Settings initialise(Properties settings) {
        instance = new Settings(settings);
        return instance;
    }

    public static Settings get() {
        return instance;
    }

    private final Properties settings;

    private Settings(Properties settings) {
        this.settings = settings;
    }

    public String getProperty(String key) {
        return settings.getProperty(key);
    }
}

然后，您的 Spring 配置将使用 factory-method="initialise" 而不是构造函数，并且其他代码可以使用静态 get() 方法来检索单例。您避免了 Properties 对象的重复，虽然静态单例本身有点反模式，但代码更有意义。

但这是我在寒冷的星期六早上能想到的最好的方法:)

Answer 2

这是一个很好的问题，我希望你能得到一些有根据且有充分理由的回答（比我预期的要好）。

不使用这种方式的原因和当初采用Spring框架的原因是一样的：控制反转、松耦合等。也就是说，我觉得如果你已经在这种情况下考虑了这些要点，但仍然觉得这种方法可以优雅地满足您的实际需求，请继续。

有时我觉得 Spring——实际上是许多领先的框架和技术——允许自己陷入“我的方式或高速公路”的 API 设计，其中克服 Spring 限制的唯一方法是使用更多的 Spring。

不应该这样。您应该能够在现有项目中采用 Spring 之类的东西，而无需注册重新构建应用程序的每一部分。

事实上，在 Spring 和非 Spring 世界之间共享对象有 365236 种方式（您的合二为一）。没有技术限制；但是狂热者会给你带来悲伤。