これは、私が Java EE を始めたばかりの頃と同じ質問です ;-)
コントローラーの概念をサーブレットに既に直接マップしているようです。これは、サンプル プロジェクトに当てはまる場合があります。しかし、より現実的なプロジェクトでは、これは当てはまりませんし、保守も容易ではありません。したがって、私の次の回答では、コントローラとサーブレットは 2 つの異なる概念であることを念頭に置いてください。最初に 2 番目の質問に回答するつもりです。
Q2:
サーブレット マッピングは web.xml でハード コードする必要があるため、非常に面倒です (つまり、Java コードを記述してから XML を記述することを好みますよね?)。現在、主流の MVC フレームワーク (struts、Spring MVC など) はすべて同様の方法を使用します。単一の「ディスパッチャー」サーブレットの練習。
このサーブレットがフレームワークをブートストラップし、カスタム コントローラーをロードすると、アプリケーション全体が有効になります。このディスパッチャ サーブレットは、さまざまなリクエスト パスやクエリ パラメータなどに基づいて、正しいコントローラを見つける役割を果たします。
Q1:
ビューごとに 1 つのコントローラー、または複数のビューに対して 1 つのコントローラーの場合、それに関する単一のベスト プラクティスはありません。私の提案は、コードをクリーンで一貫性のあるものに保つことができる限り、プロジェクトに適した戦略を選択することです。結局のところ、これはコードを整理するための味です。
コントローラーとビューは、関心のある問題を分離するための 2 つの異なるレイヤーですよね?
ところで、主流の MVC フレームワークの設計ドキュメントを取り上げることを強くお勧めします。パズルを説明するには、それらの方がはるかに優れていると思います。
外部参照:
http://www.jpalace.org/docs/articles/mvc/mvc.html これは、ディスパッチ サーブレットの実装に関する優れた記事です。実際には、MVC デザイン パターンを使用して、非常に小さいが完全なフレームワークを構築します。
http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html上のチャートは、ディスパッチャ サーブレットがフレームワークで何をするかをよく説明しています。