Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-02-14

Catalystの良さ

02:54 |  Catalystの良さ - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystの良さ - dann@catalyst  Catalystの良さ - dann@catalyst のブックマークコメント

一つは、プラグインシステムとしての気持ちよさ。デフォルトで何でもできるフレームワークでなくて、何でも「選択できる」フレームワーク。自由にプラグインを組み込めて、プラグインが選択ができる。フレームワークとしては薄くできているんだけれど、プラグインを追加すれば色々なことができる。これは、Java界隈にも、Ruby界隈にもないフレームワークなんじゃないかと思う。その点では一番進んでいるフレームワークだと思う。フレームワークとして薄くできているという点は開発者視点でみるととても有難い。

2点目は、プラグインシステムでのレイヤの置き換え。これはプラグインを選択できるというのとほぼ同じ意味なのだけれど、レイヤが固有の技術に縛られないということ。だから、ORマッパだけを置き換えたりというのも簡単にできるようになっている。

3点目は、Railsと同じなのだけれど、ERモデルを主体にしたモデル層の構築。いわゆるドメインモデルとERモデルがずれない。これは本当に開発効率が高い。PofEAAとかDomain Driven Designとかを読んでたときは、ドメインモデルとDAOは分けて、DBの作りは、そのまま上位レイヤには見えないほうがいいと思っていたことがあった。確かに美しいドメインモデルを作りたい場合にはそうなんだけれど、結局それをやるとモデル間のミスマッチを吸収するのが面倒だし、レイヤ間をつなぐのもいちいち手間がかかる。ERモデルを直にモデルとして扱うというのの快適さは、OO厨だった自分には衝撃だったし、これは大きな流れになっているんじゃないかと思う。

メタフレームワークという選択肢

01:57 |  メタフレームワークという選択肢 - dann@catalyst を含むブックマーク はてなブックマーク -  メタフレームワークという選択肢 - dann@catalyst  メタフレームワークという選択肢 - dann@catalyst のブックマークコメント

フレームワークは制御の逆転があるからフレームワークなわけで、prototype.jsはフレームワークじゃなくてライブラリなんですよね。

ライブラリは制御の流れを自分がコントロールできるから、背後の思想を理解しなくていい分、使う側は楽。一方、フレームワークは、制御の流れが逆転する分、その枠組みの中で作らなきゃいけないわけで、設計思想がわからないとつらい。設計思想がわかれば、すばらしいよねと思えるフレームワークもある。ただ、設計思想がわかってもつらいというフレームワークも数多くあって、Java界隈にはそういうフレームワークがとても多かった。

Strutsは、なんでこんなに複雑な設定ファイルを書かなきゃいけないのという、全くもって理解に苦しむフレームワークの一つなわけで、多分そういうところから入っちゃうと、フレームワークによる制約の強さとフレームワークのつくりの悪さの問題で、そもそもフレームワークの有り難味が理解できない。チームで使えば少しは有り難味がわかっても、個人で出来の悪いフレームワークを使えば、なおさら理解できないんじゃないかと思う。

Catalystは、その点ガチガチな規約はないし、どのレイヤもプラグインで切り分けられるから、フレームワークによる制約というのはさほど強いわけではない。だから、フレームワークがあるから実現できないってことは特にない。フレームワークによる制約を避けたければ、Catalystのようなメタフレームワークを使うという選択肢はある。

#ただ、ダメフレームワークといったって、大概の場合オレオレフレームワークよりはよっぽどいい。それくらいフレームワークのデザインは難しい。これはStrutsだってそう。大枠を作るのが大変なのはあるし、それを細部まで完璧にデザインしきるのは本当に難しい。だから、Strutsが使いずらいとか色々なことはあっても、それでも良くできているし、世間で使われるフレームワークの最初の一歩を作ったっていう点で、Strutsの功績は計り知れないものがあるよねというのは、書いておきたいなぁ。

ゲスト



トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080214