2008年5月20日火曜日

Springフレームワークの印象

ざくっといじってみた結果の、現時点での印象を書きます。

【良い点】
・とにかくデザインが素晴らしい
Spring上で開発されたアプリは、コンポーネント間の結合粒度が粗くなります。その結果↓
 ⇒ インターフェースがきちんと分かれる
 ⇒ 各コンポーネント(クラス)が独立して開発可能です。変更の影響範囲も分かり易い。つまり Spring で開発していると「UTやっておけば大丈夫」という「おおむね安心という心証」を得る機会が多くなります。これは素晴らしいことです。

Struts はシンプルで機能を絞り込んでいるが故に、開発側の自由度が上がります。つまりいろいろなことが出来てしまいます。しかし、Spring 上でアプリを開発した場合は、当面「Springのお作法に従わなければならない」という不自由さはあるものの、結果としてコードがキレイに分割されることになります。
自身のデザインではなく、自身の上で稼働するアプリのデザインを実に美しく規定していますこれはすごいことです。

XML地獄は健在だと以前に書きましたが、コンポーネント(クラス)同士を疎結合するためのXMLであるとすれば、その欠点を補って余りあるデザインになっていると思います。

【中立】
POJO(Pure Old Java Object)を標榜していますが、私見ではギリギリのところで踏みとどまっている印象があります。

私の感覚では「ツールによって開発すると便利だが、いざとなったら自分でXMLやJavaソースをゴリゴリ編集してメンテナンスできる」というのが最低限の基準です。
この基準からすると、例えばXML定義ファイルが完全に正となってそこから全て生成するようなツールはアウトです(アウトプットに手を入れられなくなるため)。他にもベンダーが提供する開発ツールを離れると事実上何もできなくなるような技術もダメ(例えばEJB。WebSphere と Rational Application Developer の連携がよい例ですね)。

Ant と エディタ(あるいはeclipseの標準機能)、百歩譲って xDoclet が限界で、それ以上は勘弁して欲しいというのが個人的な基準ですが、Spring は何とかその基準をクリアしているようです(おまえの勝手な基準だろ?と言われればその通りですが)。

「何とかクリア」というのは、やはりブラックボックス的な要素(Daoなど)があるからです。しかし、そこはいざとなったらソースを読めば何とかなるはずということは分かっていて、しかしそのソースを読む時間も体力もないな、というあたりの迷いが「中立」という立場につながっています。

それから学習体力もバカになりません。結構 Spring を理解して使うのは大変だと思います。(Web で Spring を試していらっしゃる方は皆さん優秀です!びっくりします)

【現時点での要注意事項】
・ドキュメントが足りない
過渡的なものでしょうが情報が足りません。前回、チュートリアルを拡張しようと頑張ってみたのですが、結局失敗しました。その経験から(あつかましくも)言ってます。(5/23追記:成功しました。「Springフレームワークの続き(リベンジ)」
「おまえの力が足りない」と言われればその通りです。それは認めましょう。しかし「一覧表から項目を選択して、編集のために次画面に渡す」というのはどのWebアプリにも含まれるような、極一般的な作りだと思います。それが簡単に出来ないのはやはり問題だと思われました。

具体的には
-radioボタンを Spring的に動的に生成する方法が分かりませんでした。(ゴリゴリとコーディングしてしまいました)
-前画面からデータを受け取って次の画面に描画することができませんでした。(formBackingObjectのrequestからpostデータが取れませんでした)

恐らくは「私の Spring に対する無理解」「当初のデザインが根本的に失敗している」「他に有効なメソッドがあるのを見落としている」といった原因があるのでしょうが、英語のページ含めてどんなに調べても達成できなかったのは残念なところです。

【総評】
確かに素晴らしいアプリケーションです。しかし例によって(この業界でありがちなことですが)喧伝され過ぎているきらいがあります。
(ある種の人からはバカにされるかもしれませんが)Strutsと生のJDBCでゴリゴリ書くのと比べてどちらが良いか。迷って迷ってやはり Spring を選んだ方がよいような気がしないでもないということはないと言い切るにはいささかやぶさかである、といったところでしょうか。

0 件のコメント:

コメントを投稿