6

これは簡単な質問で、結論を出すことはできません。

ファイルから文字列プロパティ (例: 準備済みステートメントのクエリ) を読み込むことができconfig.propertiesます。接続先のデータベース接続を取得したいとしましょう。

この情報をファイルから取得したい場合は、クラスで次のことを実行できます。

    private static final ResourceBundle BUNDLE = ResourceBundle.getBundle("scheduler");
    private static final String DRIVER  = BUNDLE.getString("bd.driver");
    private static final String CONNECTIONURL  =BUNDLE.getString("bd.url");
....

しかし、代わりに、代わりにプロパティを使用することを多くの人が推奨しているのを見てきました。次に、次のようなもので同じことを行う必要があります(クラスを静的に保ち、適切なコンストラクターを持たない場合):

static {
        prop = new Properties(); 
        try {                prop.load(ReportsDB.class.getClassLoader().getResourceAsStream("config.properties"));
        } catch (IOException ex) {
            Logger.getLogger(ReportsDB.class.getName()).log(Level.SEVERE, null, ex);
            throw new RuntimeException(ex);
        }
    }

    private static final String DRIVER  = prop.getProperty("bd.driver");
    private static final String CONNECTIONURL  = prop.getProperty("bd.url");

では、 2 番目のほうが冗長な場合に、ResourceBundle代わりにthe を使用すべきではないのはなぜですか?Properties

4

2 に答える 2

9

では、Properties の代わりに ResourceBundle を使用すべきでないのはなぜですか?

そのためのものResourceBundleではないからです。クラスの説明は次のように始まります。

リソース バンドルには、ロケール固有のオブジェクトが含まれています。プログラムでロケール固有のリソース (文字列など) が必要な場合、プログラムは現在のユーザーのロケールに適したリソース バンドルからそれをロードできます。このようにして、ユーザーのロケールに大きく依存しないプログラム コードを記述して、リソース バンドル内のロケール固有の情報をすべてではなくてもほとんど分離することができます。

あなたのユースケースのように聞こえるものはありますか? 私はそうは思わない。

問題は純粋にプロパティ ファイルの読み込みの冗長性にあるようです。そのためのユーティリティ メソッドを記述します。次に、コードは次のようになります。

private static final Properties CONFIGURATION = PropertyUtil.load("scheduler.properties");
private static final String DRIVER = CONFIGURATION.getString("bd.driver");
private static final String CONNECTIONURL = CONFIGURATION.getString("bd.url");

確かに、そのような順序に依存する方法で静的フィールド初期化子を使用することに熱心ではありません...すべての構成を別のクラスにカプセル化したくなるので、次のように書くことができます。

private static final SchedulerConfiguration CONFIG = 
    SchedulerConfiguration.load("scheduler.properties");

次にCONFIG.getDriver()、毎回プロパティから取得できる etc を使用するか、フィールドを使用します。

于 2013-02-14T20:14:40.693 に答える