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

Choistudy の組成 (1)

ここで書こうと思っていた話の続きを・・・。

Choistudy もいわゆるインターネットサービスですが、その組成Seasar2 + Cubby + S2Dao (+ S2DaoCodegen の Choistudy 用カスタマイズ)+ Mayaa です。TopHatenar さんと結構似ていたので、以前のエントリでは思わず反応してしまいました。Choistudy では、最初のサービスインまでに、二人がかりで「初めて Cubby を使う」からはじめ、ニ週間強の開発期間だったかと思います。(S2/S2Dao/Mayaa は経験ありでしたが)

Cubby については TopHatenar の kaiseh さんや jfut さんも書かれていたとおり、シンプルで軽い、HotDeploy に対応している、URL が綺麗といった点は私もおおいに賛同する所です。さらに Maven との相性が良いことも大きなポイントでした。archetype から作れて、tomcat:run で試せる所まで一連の流れがドキュメント化されていますし。

また、しばらく利用してみて良いなぁ思うこととして、

という事でしょうか。(「薄く」というのはコードが少なく、シンプルに実装されている、というニュアンスです)。「薄い」が故に、ソースも追いやすいですし、そのため基本動作の部分を把握しやすいと思っています。これは

という事に起因するのではないかと思っています。というのも、Struts の話題の中では、よく設定の XML 書くのが大変、というのを目にしますが、何故 XML を記載しないといけないかというと、アクションとフォームの「バインディング」であったり、バリデーションとフォームの「バインディング」であったり、スコープの設定等が必要であるためです。で、これらの設定はフレームワーク側にて

といった処理がなされるわけです。この処理は当然フレームワーク内にソースとして記述されますが、本質的なフレームワークの動作を追うという観点でいうと、少しはずれてくるわけです。

で、まさにこの辺りは DI コンテナの得意な所でしょう、と。ここらへんを気持ちよく DI コンテナに任せているが故に Cubby は「薄い」と思いますし、見通しが良いなぁ、と感じる次第です。(勿論これだけでなく、フレームワークの設計自身がすっきりしているなどの要因はあると思いますが)

通常利用する側からすれば、あまり気にならない所かもしれませんが、私個人としては、ある程度フレームワークの基本動作を押さえて置きたいという心理がありますので、その辺りのツボにはまっているのかもしれません。

と、とりあえず Cubby の所までで長文になったので、(1) をつけて、また次回に。。。