ContextLoaderListener: 必要な悪か、不必要な複雑さ?

開発者は Spring Web アプリケーションで ContextLoaderListener と DispatcherServlet の使用によく遭遇します。しかし、やっかいな疑問が生じます。なぜ単純に DispatcherServlet を使用してすべての設定を管理し、2 つのコンテキストの複雑さを回避できないのでしょうか?

ContextLoaderListener と DispatcherServlet の目的

ContextLoaderListener は設計されていますアプリケーションの起動時に Web 関連以外の構成をロードします。逆に、DispatcherServlet は、コントローラーやビュー リゾルバーなどの Web 固有の要素の処理を担当します。この分割により、2 つのコンテキストが作成されます。ContextLoaderListener によって処理される親コンテキストと、DispatcherServlet によって管理される子コンテキストです。

DispatcherServlet だけでなく両方を使用する理由

伝統的に、この 2 つは-context パターンは、Web 以外の依存関係を分離し、複数の DispatcherServlet を共存できるようにするなどの理由から推奨されています。ただし、最近のシナリオでは、これらの利点はそれほど重要ではない可能性があります。

ContextLoaderListener を削除するための引数

複数の DispatcherServlet がないこと、または Web 以外の依存関係が必要ないこと現在のアプリケーションでは ContextLoaderListener を冗長にすることができます。 DispatcherServlet によって管理される単一のコンテキストに構成を統合することで、アプリケーション構造が簡素化され、コンテキスト間の潜在的な競合が排除され、トラブルシューティングが合理化されます。

注意事項

ContextLoaderListener を削除すると、利点はありますが、考慮すべき潜在的な欠点もあります:

• バックグラウンド タスクが欠落しています: バックグラウンド タスク (スケジュールされたタスクなど) に依存している場合は、DispatcherServlet が負荷を伴うように正しく構成されていることを確認してください。 -on-startup は、実行の遅延を回避します。
• レガシーまたは非 Spring サーブレット: アプリケーションが、Web アプリレベルのコンテキストに依存するレガシーまたは非 Spring コンポーネントと統合する場合、 ContextLoaderListener を保守する必要がある場合があります。

結論

やむを得ない理由がない場合は、ContextLoaderListener を削除して単一のコンテキストを利用すると、シンプルさと保守性が向上します。 Spring Web アプリケーション。ただし、この移行を行う前に、アプリケーションの依存関係を慎重に評価し、潜在的な欠点を考慮してください。