0

内部にある ear ファイルとしてパッケージ化されたアプリを継承しました

 - ear :
        -APP-INF/lib (persitence.jar - hibernate+spring ... etc)
        -war (web-services)
        -jar (mdb)
        -jar (mdb)

アプリを調べたところ、各モジュールが jar 内にあり、実行時に読み込まれる独自の Spring アプリケーション コンテキストが作成されることに気付きました。

問題なく動作しますが、アプリケーション コンテキストが 1 つだけのほうがよいとは言えませんか? この構造が単一のアプリケーションコンテキストのみを使用する場合と比較して、この構造の利点と欠点は何ですか?

ランタイムをより明確にするために、3 つのアプリケーション コンテキスト ルートがロードされています。より多くのアプリケーション コンテキスト ファイルがあるだけではありません。

ありがとう

4

4 に答える 4

4

まず第一に、それがどこでも同じアプリケーションコンテキストではないことを確認しますか？これをテストしましたか？

それらがすべて分離している場合：利点は、これらのアプリケーションコンテキストが互いにシールドされていることです。これは、ルーズカップリングと呼ぶことができます。これは良いことです。一方が他方に影響を与えることはできません。プログラマーにとって物事をより明確に保ちます。欠点は、一方のアプリケーションコンテキストにもう一方のアプリケーションコンテキストからアクセスするのが難しい場合があることですが、これを回避する方法はいつでも見つけることができます。

于 2012-06-07T06:14:16.923 に答える
3

アプリケーションが非常に大きい場合、異なるモジュールのアプリケーション コンテキストは管理が容易であり、オーバーヘッドは発生しません。アプリケーションが起動すると、すべてのコンテキスト xml ファイルが結合されます。

また、個別の構成セット用に個別のアプリケーション コンテキスト ファイルを維持することも好みます。security、datasource、aop などは別のコンテキスト ファイルに配置する必要があります。

アプリケーションが小さい場合は、アプリケーション全体に対して単一のアプリケーション コンテキスト ファイルを使用できます。それ以外の場合、モジュールごとに異なるアプリケーション コンテキストを管理するのは簡単です。それらすべてを組み合わせると、それを変更することは非常に困難になります。

これがお役に立てば幸いです。乾杯。

于 2012-06-07T06:12:17.820 に答える
1

私が考えることができる単一のアプリケーションコンテキストファイルに対するいくつかのポイント:

  1. 1 つのファイルが巨大になり、メンテナンスの悪夢になります。
  2. 各コンポーネントの開発者が同じファイルを変更、更新すると、エラーが発生する可能性があります。
  3. 1 つのコンポーネントを変更すると、1 つの中央ファイルが変更され、再び問題が発生する可能性があります。
  4. これにより、すべてのコンポーネント開発者に「関心の分離」がもたらされます。彼らは、タスクを実行している間に他の人が作業していることを確認する必要がありません。
于 2012-06-07T06:12:24.830 に答える
0

マルチテナント アプリケーションのソリューションを探しているこのスレッドに出くわしました。ほとんどの記事はデータソース (Spring HotSwapable データソース ターゲット) などに関するものですが、あなたが持っているのは戦争レベルでの別のコンテキストです。

これにより、アプリケーションをマルチテナントにする方法でバンドルするという別のアイデアが得られます。war が特別なランタイムを挿入し、追加のコンテキスト パス資格を提供するためだけにスキニーである場合、これは大規模なマルチテナント アプリケーションで機能する可能性があります。共通クラスは、war ごとに EAR レベルおよびアプリケーション コンテキストでロードされます。テナント数が少ない場合はこれで十分だと思います。

于 2014-03-05T22:19:31.540 に答える