0

次のように別のプロジェクトがあります。

  • a)ビジネス層(すべてのコア Java クラスといくつかの構成 (サービスなど) を含む) および

  • b)プレゼンテーション レイヤー(Spring Webflow に基づくすべての Web 構造と、その上のすべての構成ファイルを含む。したがって、開発の過程でjava/main/src、パッケージの下にいくつかのプロパティ ファイルが分散さresource.properties.*れ、Web 構造の下に他のプロパティがあります。 WEB-INF/conf そしてWEB-INF/i18n（これは画面のラベルメッセージです）..だから私の質問は次のとおりです：

    1. 後でwebapp? のフォルダーのjava/main/src下にあるパッケージの下にプロパティ ファイルを残すのは正しいことです 。classes
    2. すべてのプロパティ ファイルを 1 か所に残す最適な方法はどれWEB-INF/configurationsですか。または、ビジネス レイヤーの一部のプロパティ ファイルを 1 つの場所に残し、プレゼンテーション レイヤーの一部のプロパティ ファイルを別の場所に残しますか?
    3. このプロパティを webapp をインストールする最良の方法で使用するための最良の方法はどれですか?、プロパティを JAR ファイルで配信し、それを WAR または EAR に含めますか? これにより、アプリケーション全体を展開することなく、その場で変更して戦争に含めることができます...またはそれを達成するための最良または使用されるアプローチはどれですか?
4

2 に答える 2

1

プロパティを 2 つのカテゴリに分けるのに役立つことがわかりました。

  1. アプリケーションの外観と動作を便利に変更するためのプロパティ
  2. 環境固有の設定のプロパティ (DEV と PRODUCTION など)

カテゴリ #1 は、意味のある場所ならどこでも WAR ファイルに埋め込むことができます。inWEB-INF/classesは人気のある場所ですがMETA-INF、jar ファイルに入れることもできます。好きな基準を選んで、それに固執する価値があります。要するに、これらのファイルは開発中に変更されるということです。それらは展開後に変更されず、システムがリリースされても同じままです。

カテゴリ #2 は、常にデプロイ可能なものから分離する必要があります。理想的には、環境固有のプロパティは、変更された場合にのみ展開する必要があります。彼らがどこに住むかは、実際には構成管理 (CM) の決定です。開発者はこれらの構成ファイルの基本バージョンを提供する必要があり、CM は、特定の環境 (QA、PRE-PROD、PROD) に展開されるときにそれらを編集する必要があります。職務の委任が義務付けられている状況 (SOX が適用される場合など) では、開発者がプロ​​パティ ファイルの製品バージョンに触れたり、見たりしてはなりません。これらのファイルのさまざまなバージョン (DEV/QA/PROD) が開発者によって維持され、ソース管理に保管されている多くのケースを見てきました。これは適切ではありません。

于 2013-03-25T14:45:54.143 に答える
0

別のソース フォルダー 'resources' を用意し、そこにすべてのプロパティ ファイルを保持するのは良いことだと思います。これらにより、プロパティ ファイルがソース コードと混同されないようにすることもできます。

于 2013-03-25T14:34:00.827 に答える