フロントコントローラーはサーブレットでしたが、Struts2 ではフィルターです。フィルターに変更する理由として考えられるものは何ですか?
3 に答える
(これは意見です。元の WebWork の作成者に尋ねる必要があります。)
IMO は、フィルターがそのために設計されているため、フィルター内にリクエストをラップする方がもう少し直感的です。
フィルターからリソースを提供することの妥当性については議論がありました。仕様には次のように記載されています。
通常、フィルターは、サーブレットのように応答を作成したり、要求に応答したりしません。むしろ、リソースの要求を変更または適合させ、リソースからの応答を変更または適合させます。
一部の人は (特に一部の WebSphere サポート チケットと、Struts ユーザー メーリング リストの電子メール スレッドで仕様を再読する前に私自身)、仕様が Struts 2 のフィルターの使用を許可していないと主張していますが、このような方法での使用を禁止するものは何もないことは明らかです。 .
<dispatch>
フィルターを使用すると、構成中の要素を使用して、他の種類の要求 (転送、インクルード、およびコンテナー エラー) をより柔軟に処理<filter>
できます。
元は WebWork のサーブレットであったことに注意してください。変更が発生したときはいつでも、コミット ログを調べて理由を突き止めることができるかもしれませんが、それはかなり前のことで、7 年以上前のことです。
struts2 にインターセプターが導入されたためです。Struts2 のコントリビューターは、ユーザーが Java EE パターン内の脅威に違反できないように、メイン コントローラーを正面から持つことが必要になります。ただし、Struts2 ディスパッチャはサーブレットの階層の最上位に構築されますが、セキュリティの観点から多くの労力を軽減します。
理由:
- フレームワークに集中型コントローラーを提供します。
- あなたの指で踊ることができるインターセプターとコンテキストを持つこと。
Strtus2 でフィルターがフロント コントローラーとして指定されている理由は 3 つあります。
フロントコントローラーとして作成されたサーブレットでは、コンテナーの起動時にフレームワークが多くの重要な側面 (つまり、struts 構成ファイル) を初期化できるようにする適切な値を開発者が提供する必要があります。フレームワークが初期化されない場合、最初のリクエストがヒットしたときにのみ初期化されます。Struts2 はフロントコントローラーをフィルターとして提供することで私たちの生活を楽にし、本質的に web.xml のフィルターはコンテナーの起動時に自動的に初期化されます。そのようなロード オン スタートアップ タグは必要ありません。
2 つ目の重要な点は、Struts2 フレームワークにインターセプターが導入されたことです。これは、コーディング作業を削減するだけでなく、Struts1 ではなく web.xml でコーディングと必要な変更にフィルターを使用していたコードを作成するのに役立ちます。そのため、フィルターに適したコードはインターセプターに移動できるようになりました (フィルタよりも制御しやすい)、すべての構成は struts.xml ファイルで制御でき、web.xml ファイルに触れる必要はありません。
フィルタであるフロント コントローラは、Struts の新機能、つまり UI テーマにも役立ちます。テーマ内のすべての静的リソースがフィルターを介して提供されるようになりました