JSFや他の多くのWebフレームワークで、どの部分がMVCのどの部分に対応するかが完全に明確でないことが多い理由の一部は、MVCパターンが元々デスクトップアプリケーション用に考案されたためです。
デスクトップアプリケーションでは、ノードM、V、およびCは最大連結グラフです。つまり、各部分は他のすべての部分と通信できます。たとえば、モデルが変更された場合、この変更をビューにプッシュできます。これは、デスクトップアプリケーションにビューの複数の表現がある場合に特に顕著です。1つを変更し、もう1つの更新をリアルタイムで確認します。
Webアプリケーションのクライアント/サーバーおよび要求/応答の性質により、従来のMVCはほとんどのWebフレームワークに1:1でマップされません。
具体的には、JSFでのマッピングは次のとおりです。
- モデル-サービス/DAOとそれらが生成および消費するエンティティ。これへのエントリポイントはマネージドBeanですが、Java EE(JSFがその一部である)では、これらのアーティファクトは通常、それぞれEJBとJPAによって実装されます。
- 表示-UIコンポーネントとその構成を1ページにまとめます。これは完全にJSFのドメインにあり、それぞれJSF
UIComponent
とFaceletsによって実装されます。
- コントローラ-ユーザーからのコマンドと受信データを処理する交通警官は、これを適切な部分にルーティングし、表示するビューを選択します。JSFでは、このコントローラーを作成しませんが、フレームワークによって既に提供されています(これは
FacesServlet
です)。
特に最後の部分はよく理解されていません。JSFではコントローラーを実装していません。したがって、バッキングBeanまたはその他の種類のマネージドBeanはコントローラーではありません。
最初の部分(モデル)も必ずしも明確に理解されているわけではありません。ビジネスロジックはEJBとJPAによって実装できますが、JSFの観点からは、値バインディングによって参照されるすべてがモデルです。これは、JSFライフサイクルフェーズの1つの名前の由来でもありますUpdate Model
。このフェーズでは、JSFはUIコンポーネントからモデルにデータをプッシュします。その意味で、(JSF)マネージドBeanがモデルです。
JSF自体は概念を明示的に定義していませんが、バッキングBeanと呼ばれるマネージドBeanの使用法が頻繁に繰り返されます。
JSFの場合、バッキングBeanは引き続きモデルですが、実際には、モデル、ビュー、およびコントローラーの中央にある配管要素です。いくつかのコントローラータスクと見なされる可能性のあるいくつかのタスクを実行するため、これはコントローラーと間違われることがよくあります。しかし、前に説明したように、これは正しくありません。また、いくつかのモデルタスクを実行したり、場合によってはいくつかのビューロジックを実行したりすることもできます。
参照: