JSFとCDI使ってWebアプリをいじっていたら、やっとわかったきがした(゜▽、゜
なにがって、なんていうか、実現する構成の方向性みたいなのが。
JSFはStrutsと違ってコンポーネントベースって言われるフレームワークなのね。
Strutsは、URLへのRequest(引数)に対して対象のAction(関数)を呼んで、画面(戻り値)を返す感じ。
JSFは、URLに対応する画面(オブジェクト)があって、画面のアクション(イベント・メソッド)で、状態を変化させていく。
まぁ、どっちもまともに使ったこと無いけど(笑)
Strutsは関数指向。JSFはオブジェクト指向な感じだね。
関数指向は処理が分散しがちでメンテナンスはちょっと気を抜くと大変なことになる。
オブジェクト指向は、正しく作ればメンテナンス性は高くなるけど、処理を分散しにくい。
そうなると、棲み分け的には、
クライアントのアプリとかは、オブジェクト指向で作って、
最近よく聞く、クラウドっていうのは、関数指向で作ることになるんだろうね。
まぁ、オブジェクト指向は、関数指向を受け入れない訳じゃないから、
ハイブリッドとかもあり得るだろうけど。
まぁ、普通の(?)Webアプリ作るならJSFの方が管理とかはずっと楽って言うこと〜。
そして、クライアントとサーバーをまとめて見下ろすと、なんか別の世界が見えてきた。
「あ、これってWPFと同じMVVMじゃん。」
結局、『.NET』も『Java』も行き着くところに行き着いた。という感じなのかな?
MVVMって言うのは、MVCの派生みたいなの。Model-View-ViewModelって感じのやつ。
難しいことはよくわかんないけど、わたし的解釈は、下(↓)に書いたような感じかな。
「画面(View)と画面に出すもの(ViewModel)の関係は、
View→ViewModelでしかもバインドとして疎結合であるべき。
Modelからの依存は許さない。」
バインドってことはその外側でバインディングを管理している人がいるわけなのをお忘れ無く!
フレームワーク | View | ViewModel | Model |
---|---|---|---|
WPF | .xamlファイル | .xaml.csファイル | その他 |
JSF+Weld | .xhtmlファイル | .xhtmlに対応した(Managed)Bean | その他 |
結局、どっちもViewに対してViewModelを割り付けて、
Viewで発生したイベントをViewModelで拾ってModelに流してるのね。
JSFだけだと、Modelを完全に切り離すのがめんどくさそうなので、Weldの力を一緒に使うのが良さそう。
っていうことで、Webアプリを作るならJSF+CDI(Weld)が楽っぽいなー。
特にわたしはクライアントアプリ中心にオブジェクト指向でやってきたし(笑)