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

かとじゅんの技術日誌

技術の話をするところ

Seasar Con 2008 Springに行ってきました

Seasar

いやー,今週は公私ともにパツパツ.

今回参加してわかったこと(個人的な意見が含まれます)

Teedaは捨て去られたものではない.

Teedaは1.0系を安定化させ,1.1系はちゃんと進化していく.これを聞いて安心した人は多いかもしれません.Teedaが登場してその後にSAStrutsがぐわーっと話題になってTeedaはどうなるんだろう感があってw,Seasarプロジェクトとしてどちらのフレームワークに力点を置くのかという疑問があったわけです.でも,話を聞いてやっと理解できました.開発案件の特性に応じて使い分けることが重要って話なんですね.開発者にとってよりよい選択肢が増えるということですね.
ひがさんの口から今後のロードマップについてはっきりと説明があったことはよいことだと思います.今後,Teedaが枯れながらも,正常進化を遂げていく過程でウェブや書籍の情報も市場に浸透されていくことを願います.
追記:表現がざっくりしすぎましたw 悪い印象を与えた方 陳謝いたしますm(_ _)m

やっぱり金字塔はStrutsか!?

金字塔はStrutsであるが生産性が悪すぎる.これをSAStrutsが解決することでより現場指向のエンジニアリングを可能にする.ActionがちょうどTeedaのページクラスに見えました.ViewはHTMLテンプレートがほしいならMayaaを使えばよいとお話ですが,Teedaのようにもう少し軽いView層はございませんか?という意見もある.あまり感動はなかった.

DBFluteはstrictな最強O/Rマッパー

DBFluteSeasar系のDaoパターンのO/Rマッパーとしては最強.S2DaoがCoreとすれば,DBFluteは名前は違えどS2DaoのExtension的な位置づけのO/Rマッパーといえばわかりやすいかもしれません.でも,実際使い始めるとS2Daoが内部で利用されていることをあまり感じなくてもさくさくと開発できるかもしれません.それほどS2Daoをかなり強化したフレームワークだと思います.

S2JDBCって?

S2JDBCはDaoを書かなくてよい.というかSQLパターンのO/RマッパーなのでDaoという概念がなくマネージャーとエンティティしかない.本当にSQLをコード補完で直観的さくさくっと各感じ.クラスを増やしたくない.永続化層をなるべく小さくまとめたいという場合は使うかもしれません.でも,?とはinとか,descとか書かせるのはどうしても抵抗感を感じてします.自分一人ならまだしも.自分はやっぱりstrictなS2Dao,DBFluteが好きです.

Slimブランド戦略

Slimがトヨタのレクサス的に別のブランドとして展開されると点,理解した.SAStrutsS2JDBCはこのための布石だったのですね.
でも,何やら話を聞いていてフレームワークのジレンマを感じました.フレームワークが肩代わりするからアプリケーション部分の実装は薄くなる.フレームワークが薄いと学習コストが減る,カスタマイズしやすい.でもアプリケーションでやるべきことが増える傾向にある.フレームワークで解決する問題を細分化して,それに対応する機能を開発者が選択できるようにならないもんでしょうか.core, extensionってjarを分ける理由もその一環と言えると思います.実はextensionもさらにニーズが細分化される可能性があって,TeedaだってHTMLテンプレートを使うがPRGパターンは使いたくないという携帯サイトの開発者など.このような想定でフレームワークを作る側はある意味手間ですが,こうなれば開発者側で必要最低限に薄いフレームワークを用意して開発できるのではと思ったりしました.逆説的にいえば,SAStrutsでも足りない機能を補完するフレームワークが登場してくれば使う気になるかもしれません