大学のプロジェクトで Web アプリケーションを開発していますが、Java EE を使用してドキュメントを提供するように言われました。インターネットでさまざまなことを言っている記事を見つけたので、MVC パターンを多層アーキテクチャに適合させる方法とそれらを記述する方法を理解するのに苦労しています。
私が読んだことから (特に sun.java.com の BluePrints について)、4 つの層 (クライアント、Web、ビジネス、およびデータ) を使用する必要があり、ビジネス ロジックは Web 層とビジネス層に分割されていますね。次に、MVC パターンを使用して、これら 2 つのレイヤーを整理します。
私は正しいですか？
Java EE の MVC にはいくつかのアプローチがあります。
少し古いアプローチ (ただし、コンテキストによってはまだ有効) では、ビューに JSP を使用し、コントローラーにサーブレットを使用します。モデルが正確に何であるかについてはよく議論されますが、通常は、ドメイン エンティティ (JPA エンティティなどで表される) を返すサービス (EJB セッション Bean などで表される) であると見なされます。
Java EE の最新バージョンには、JSF と呼ばれるデフォルトの MVC フレームワークがあります。このフレームワークに従って、ビューに Facelets が使用され、コントローラーが提供されます (実装する必要はありません)。
モデルと呼ばれることが多い と呼ばれる中間概念がありますがbacking bean、それ自体は純粋なモデルではありません。代わりに、実際のモデル (EJB サービスなど) に委譲します。バッキング Bean は、一部のコントローラーの役割を担うこともできます (リダイレクトの発行、またはビューを表示するための一種のキューへのメッセージの配置)。
Web およびビジネス層を作成するのはやり過ぎだと思われることがありますが、必ずしもそうである必要はありません。多くの場合、適切なオブジェクト指向の原則を適用するだけの問題です。もう 1 つの極端な例として、すべてを JSP に詰め込む (html コード、コントローラー ロジック、およびビジネス コード) ことは、はるかに悪いことです。
3 層 (実際には 3 層) の Java EE MVC アプリケーションがいかに単純であるかを示す次の例を参照してください。
関連する質問はこれです:昔ながらの 3 層パターンに対する MVC パターンの主な利点は何ですか?
サーブレットを使用する場合、それはすでに Java EE です。
不必要に複雑にしないでください。Web ユーザー インターフェイスしかなく、他のユーザー インターフェイスがない場合、Web 層とビジネス層の両方に分割するのはやり過ぎです。