NetBeans6.0 + glassfishV2 + JSF + EJB3 + JPAを業務でしばらく使ってみた感想
この3週間NetBeans6.0 + glassfishV2 + JSF + EJB3 + JPAを業務で気合入れてさわってみた感想を。
JSFについて
JSFはライフサイクルを常に意識する必要があるので、やっぱりstruts等アクションベースのフレームワークより敷居は高いと思う。その引き換えにアクションベースに比べて圧倒的な開発効率が得られるわけだが、ノウハウがたまるまではちょっときついかも。
JSFとJPAとの相性がいいのでは?と以前言ったことがあったけど、それは嘘*1かも。ライフサイクルを意識してidを紛れ込ませないとダメ。それがわかればなんとでもなるけど、そういうところを見るとJSFって実装がステートレスのくせにステーテフルもどきをやろうとしてすごい苦労しているのがわかる。もう、思い切ってステートフルで実装してしまったほうがよっぽどわかりやすいような気が。
つまりJSFはセッションを多用すると難易度は大幅に下がり、リクエスト単位で処理をしようと思うとやや面倒になる。Visual Web JSFでいうところのpageビーンをセッションスコープにおいてどれだけメモリを食うのかを検証して問題ないようだったらすべてセッションで管理するのもいいのかもしれない。本当はEJBコンポーネントをマネージドビーンとして扱えるようになればステートフルの問題はすべて解決するんだけれども、それは現在策定中のWebBeansがでてからの話でしょう。標準技術ならばNetBeansは必ずサポートしてくるはず。
Visual Web JSFについて
Visual Web JSFはとにかくマシンパワーを食う。メインメモリ1.5GBで使ってるけど、ちょっと足りない感じ。1台ですべて動かそうと思うと2GB以上ほしい感じ。
Visual Web JSFは標準コンポーネントのデータテーブルのページングにバグがあるし、webuiコンポーネントのテーブルは一見便利そうに見えて癖が強く、これまたバグも多い。こうすればバグが出るというのはすぐにわかると思うので回避も容易だが、このバグがなかったら作業効率はさらに高くなるだろうと思うとかなり悲しくなる。テーブルは頻繁に使うコンポーネントだし。
また、woodstockカレンダーコントロールも月末バグがあるので使用する場合はユーザーにバグがあることを説明しておくこと。非常に便利なコンポーネントだけにもったいない。Visual WEB JSF自体バグが大量にあるまま正式版がでたが、6.1までは放置くさいのが残念。
glassfishについて
現状glassfishのEJBはLocalしか日本語が通らないのでRemoteにテストケースを書いて実行している。おかげでNetBeansのJUnitサポートが役に立たない。ここだけは圧倒的につらい。
再現するプロジェクトをsunの橘さんにお送りして、確認していただいたので近いうちに解決されるでしょう。これが解決されてはじめて日本でglassfishやJPAが使えるようになるといってもいいくらい。ところでNetBeans6.0.1MLにはMLじゃないglassfishが同梱されているのはなんでだろ。
アプリケーションサーバーとしてはTomcatからJavaEE5対応AP鯖への置き換えをそろそろするべき時期に来ていると思う。
JPAについて
JPAはJavaSEな環境でも動くことを売りにしている。だが、やはりJavaEE、つまりアプリケーションサーバーの上で動かしたほうが、問題点が少なく、開発効率等もあがるためお勧めする。JavaSE上でしかJPAをさわったことがないのならぜひJavaEEな環境で触ってみてほしい。ユーザーは純粋に開発に集中することができる。
現状もっとも手軽に扱え、問題点も少ないO/Rマッパだと思う。NetBeansに限らず各種ツールのサポートが多い点もメリットだ。ツールのサポートなしでの開発ならばJPAは他に劣ることも多いのかもしれないが、ツールサポートを前提に開発するならこれを越える環境はなかなかでてこないのではないだろうか。
開発効率について
悪いことばかり書いてきたが、触れば触るほど、不具合が目に付き、バッドノウハウをためることはどの環境でも当たり前のこと。いい点しかアピールしない評価というのは信用に値しないと個人的に思っている。何ができて何ができないのか、そこが大事だから。
で、NetBeans6.0の良い点として圧倒的な開発効率があげられる。実作業時間として19日間で18画面作れた。内一つだけ難易度がやや高く、3日も費やしため、残りは16日で17画面分。この期間にはビュー周りのみではなくて、テーブルの作成からEntityクラスの作成、画面に伴うビジネスロジックの作成なども含むので悪くはない結果だ。EJBの単体テストが手軽に出来るようになればさらに効率よく作ることが出来るだろう。
実働25日で20画面が作れれば御の字と割り切ってはいるのだが、このペースが最後まで続けば予定通りかそれ以上というところ。Java + PostgreSQL + JPA + NetBeans以外でこの開発効率は私はだせそうにない。
JSFベースの他のフレームワーク*2としてはTeedaがあると思うけど、機能的にはファイルアップロードとネストしたプロパティやglassfishがサポートされるようになってからが本当のスタートでしょう。ターゲットが違うだろうから業務目的ならばVisual Web JSFに開発効率ではおそらく勝てない。Clickあたりがおそらく対抗馬でしょう。
Visual Web JSFは簡単な画面を簡単に作るという点においてかなり便利。6.0からはプロジェクトは通常のWebプロジェクトと統合されているので、VisualWebを使わないJSFや他のサーブレット/JSPを使用することも出来るためいくらでも抜け道はあると割り切って積極的に採用してみるのをオススメする。もちろん、VisualWebJSF自体JSFの上にかぶせるフレームワークなので、数ヶ月の勉強期間はあらかじめとっておいたほうがいい。まずはシステムの管理ツールで導入してみるといいだろう。管理ツールは定型的で単純だが、画面数が増えるタイプのシステムだから。
