Spring MVCでのコンテキストの理解

Question

私は春に新しく、簡単なWebアプリケーションを作成しています。私はSpring MVCのコンテキストについて読んでいます。

私はEclipse用のSTSプラグインを使用しています。プラグインを使用して Spring MVCプロジェクトを作成しました。

ここでは、プロジェクトにweb.xml、root-context.xml、servlet-context.xmlの3つのXML文書があります。これらは私のためにSTSによって作成されました。

1. web.xmlで、ディスパッチャサーブレットは、サーブレットのcontext.xmlの方に指摘されており、私は、ディスパッチャサーブレットジョブがビューを解決する方法を知っているとするコントローラ豆のための場所であるWebアプリケーションコンテキストを作成することであることを理解します存在する。 私の理解は正しいですか？もしそうなら、この文脈によって他のどのような仕事が達成されるでしょうか？

2. ここでは、プロジェクトのデフォルトパッケージにコンポーネントスキャンを含むroot-context.xmlというファイルがあります。私の理解では、このコンテキストは、多くのサーブレットが使用できるグローバルBeanを持つ必要があります。私の理解は正しいのですか？これ以外に何がありますか？このファイルを使用してどのようなコンテキストが作成されますか？

3. 私はさらにプロジェクトに沿っており、contextLoaderListner（web.xml）を使用してロードされるいくつかの* -context.xmlファイル（dao-context.xml、security-context.xmlなど）を持っています。これは良いアイデアですか？あるいは、すべてがservlet-context.xmlに入るはずですか？私はそれが懸念の分離を提供するので、異なる文脈を持つことは良い考えだと思います。コメント？また、これらの* -context.xmlファイルからはどのようなコンテキストが作成されますか？これらのファイルの適切なフォルダの場所は何ですか？

4. Web.xmlはtomcatなどのサーブレットコンテナ用で、プロジェクト内の他のすべてのxmlファイルはスプリングコンテナ用です。あれは正しいですか？これらのファイルはすべて分離されており、分離の心配はありませんか？

5. 現在のシナリオでは、いくつのアプリケーションコンテキストとWebアプリケーションコンテキストが存在しますか？

なぜ複数のディスパッチャーサーブレットが必要なのでしょうか？

なぜ複数のアプリケーションコンテキストが必要なのでしょうか？

思考？コメント？訂正？ベストプラクティス？

Answer 1

このデザインの背後にあるアイデアは、一般的なWebアプリケーションでさまざまなアーキテクチャレイヤーを処理し、コンテキスト間でBeanの継承/オーバーライドメカニズムを提供することです。

SpringベースのWebアプリケーションでは、複数のディスパッチャサーブレットを設定できます（大部分の場合、サーブレットは1つですがディスパッチャですが）。それにもかかわらず、serlvetはサーブレットであり、複数のweb.xmlが設定されている可能性があります）。これらは、異なるURLパターンを扱うように設定できます。したがって明らかにそれぞれは異なるサーブレットなので、異なるSpring Webアプリケーションのコンテキストを持つことができます。これらはそれぞれ、コントローラ、インターセプタ、ビューリゾルバ、ロケールリゾルバなどのSpring Webレイヤのための異なる設定を含むことができます。これらは通常、アプリケーションのWebレイヤに属します。これらの設定とBeanはすべて、各ディスパッチャーサーブレットにプライベートなので、互いに見えません。したがって、このプライバシーを有効にするためには、別個の春のWebアプリケーションのコンテキストが必要です。しかし、共有されるように設計された他のBeanがルートコンテキストに属しています。したがって、共有可能なものはすべてルートコンテキストに属し、このWebアプリケーションにとってはグローバルと見なすことができます。

各ディスパッチャサーブレットは、ルートコンテキストで定義されたすべてのBeanを継承します。ただし、重要な点は、それぞれのディスパッチャーサーブレット固有のBeanによって共有Beanをオーバーライドできることです。したがって、Webアプリケーションでは、ルートコンテキストは継承されていても上書きできるものとして見ることができます。

Answer 2

このようにXMLファイルを作成する必要はありません。サーブレット・サーブレットのみを使用して、servlet-context.xmlとなるxmlファイルを1つだけ使用すれば、すべてをうまく処理できます。一般的には、サービスBeanやDAO Beanを定義するために異なるファイルが存在するため、これは基本的にアプリケーションの設計に依存します。例えば、春のセキュリティを使用している場合、security-context.xmlのようなXMLファイル私はそれがデザインに依存していると言いました。実際には、コンテキスト・ローダー・リスナーを完全に排除し、ディスパッチャー・サーブレットを使用してすべてを実行することができます。 あなたの質問は範囲が広すぎます。あなたが春の新製品である場合は、春の容器に関する詳細を入手し、要件に合ったものを選ぶ必要があるかもしれません。 私は通常、WEB-INF内のservlet-context.xmlとclasspathのservice-context.xmlのような他の構成を持っています。これは私にとってどのように厳しいルールでもありません。