読者です 読者をやめる 読者になる 読者になる

JSF で EoD

以前に書いたのですが JSF を使用して EoD が本当に実現されるのかすごく懐疑的です。なぜなら JSF は開発者には優しいが設計者には優しくないと考えるからです。現状、やはりまだまだウォーターフォール型で自社の人間が基本設計・詳細設計と称して大量の紙を生み出して、その紙をもとに協力会社さんなどにプログラムをお願いするケースってのは多々あると思います。ここで基本設計や詳細設計を行う役割の人間って言うのが上でいっている設計者に該当するのですが、多くの場合にその設計手法というのが OOA でもなし DOA でもなし、画面から処理を流していき、その処理に対して必要なデータがDBテーブルとして存在するというよな旧態依然とした方法で行っている場合が多々あります。レイヤ化なんて何処ふく風の縦割り一気通関で設計します。そういう設計の上で JSF を使うとどうなるでしょう?
JSFMVC モデルを前提に作られており、それをなかば強制します。書籍などの紹介でイベントドリブンなコードで簡単になんて書かれてますけどそういう風にはちっとも思えません。大抵は JSP と BackingBean を一対一で書くように紹介されていますが、V の JSP と M の BackingBean が一対一でつながるっていうのはどういうことなのでしょうか。そういう風に考えると逆にたくさんの無理が生じてしまい、割り込み処理など思想に反するような泥臭いことを頻繁に行わなければいけなくなってしまいます。JSFJSF としておいしい部分を活用しようとするとそれなりにオブジェクト指向コンポーネント指向に対して見識がないと設計なんてできません。
そういう意味合いで JSF は設計者に対してかなりの負荷をかけると考えます。ただ、だからといって設計者は旧態依然とした態度のままでいいと言ってるわけではありません。むしろこれを気に積極的に吸収していく必要があると思います。しかし如何せん視点変換に対するインパクトが大きすぎると思えるのも事実です。ウォーターフォール型の開発もマッチしない(ウォーターフォールがマッチするものがあるのかどうかは置いといて)と考えます。コンポーネント指向で開発するに当たって従来の画面から確認するだけのテストでは無駄や複雑さが増大してしまうでしょう。 JSF はあらゆるフェーズにおいてパラダイムシフトを求めます。そのパラダイブシフトの大きさに太刀打ちできないプロジェクトは混沌として EoD などと言ってられなくなると考えます。そういう観点での JSFEoD 実現の懐疑です。
個人的には JSF は非常にすぐれていると思っています。ただそれだけに逆に上記のようなことも考えてしまうのです。